Qian Wang Sanna Teiskonen Heikki Paananen Jani Liimatainen

Qian Wang Sanna Teiskonen Heikki Paananen Jani Liimatainen
Thinking Beyond Lean How Multi-Project Management is Transforming Product Development at Toyota and Other Companies (Cusumano, M. A. & Nobeoka, K. 1998) Qian Wang Sanna Teiskonen Heikki Paananen Jani Liimatainen

Outline Preface Chapter 1: Introduction: Beyond “Lean” in Product Development Chapter 2: Case study of Toyota Chapter 3: Organizing Product Development in the World Auto Industry Introduction Chapter 4: Strategies for Product Development and Multiple Projects Ch. 5 Multi-Project Strategies and Project Performance Ch 6 Multi-project Strategies and Company Performance Chapter 7. Organizational Requirements for Multi-Project Management Ch. 8 Implications and Lessons for Managers

Preface Study began by creating a database on 210 automobile products from public information This enables to determine which cars share “platforms” Platform is an underbody of an automobile and an expensive critical subsystem that defines the performance of the product Then launched a survey of several hundred project managers and engineers The survey data enabled to analyze project performance and organizational issues

Preface This book is a culmination of six years study
Overall, they interviewed 335 managers and engineers at 17 auto makers Interviews made between 1994 and 1997

Ch. 1 Introduction: Beyond “Lean” in Product Development
Book is about how to manage product development more strategically and efficiently Book discusses about multi-project management and the benefits that kind of thinking can bring to projects and 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

Projects that share components and engineering teams should overlap in time so that a firm can deliver many products quickly and utilize new technologies The evidence suggest that by following these principles firms can achieve dramatic improvements in performance In multi-project thinking firms view each development project as part of a broader portfolio of projects

Automobile manufacturers provide excellent cases to this study because: They have numerous product lines Lots of projects ongoing simultaneously Products can contain more than components Products takes a million or more engineering hours per project to develop

Critical decision for automobile companies is whether or not to organize groups around functional activities or projects So, the main question is how to balance what is optimal for the individual project versus what is optimal for the organization as a whole

In this book that question is broke down to several issues: Which functions should companies keep centralized? Which functions should companies disperse among projects? 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 technologies as well as functions at least for clusters of similar projects?

Word “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 there are two especially important lean principles: Overlapping different functional activities or development phases Using relatively independent product team led by “heavyweight” project managers

No doubt that lean thinking has significantly improved project performance: During the 1980s, Japanese auto makers required only two-thirds of the lead time for the average projects compared to U.S. companies Engineering hours per project were in Japan 1.7 million and in U.S. 3.4 million hours This efficient and rapid model change or expansion allowed Japanese auto makers to introduce new features and quality improvements into their projects as well as expand their sales

Multi-project thinking usually fits reality much better than focusing on a single projects, because Most companies have more than one product Most companies have more than one new product under development at the same time 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

Leading companies have shifted their attention beyond simply the efficient management of individual projects They now take more time in planning and focusing more on how to create innovative designs and avoid low-value features and unnecessary unique parts The best companies follow a deliberate approach and leave little to change. They create families of well-integrated products that share design concepts, key components and basic technologies

This study categorizes new projects into four types of project strategies New design Concurrent Technology Transfer Sequential Technology Transfer Design Modification

New Design Projects that develop platforms primarily from scratch 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 Concurrent Technology Transfer New project begins to borrow a platform from a base or preceding project before the base before the base project has completed its design work New and a base project overlap and that overlapping provides opportunities for effective and efficient technology sharing

Concurrent Technology Transfer Because development phases overlap chronologically, engineers in the new project and the base project can discuss adjustments in the platform and other component designs In order to make this work, the two interdependent projects often require extensive coordination and thus some from of multi-project management

Sequential Technology Transfer Project inherits a platform from a bas project that has finished its design work  the project reuses a platform design that already exists Design constraints may be very high because engineers from two projects cannot make adjustments in the platform to suit the different projects The following project may have to force changes to accommodate elements of the core design and other components from the preceding project

Design modifications This refers to a project that replaces an existing product but without creating a new platform or borrowing a platform from another product line Project simply inherits or reuses the platform from the predecessor model in the same product line Engineers have to live with any constraints imposed by platform of the predecessor

According to research auto makers that follow concurrent technology transfer more often would grow between 37 and 68 percent more over three years compared to firms that followed one of the other three strategies With concurrent technology transfer firms saved between 33 and 64 percent in engineering hours Firms also saved between 12 and 17 percent in lead times 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 us as a benchmark, introduced a new organizational structure to support concurrent technology transfer and then reduced its engineering costs for new models by 30 percent as well as cut lead time by several months

Its also important to link product strategies and organizational strategies in product development The book considers companies that success 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 the time or utilize traditional functional departments or even traditional matrix structures

Ch. 2 Case study Reorganizing for Multi-Project Management Toyota’s New Structure of Product Development Centers

Outline for chapter 2 Introduction
In early 1990s, Toyota moved beyond lean thinking and heavyweight project managers when it reorganized its product development groups around platform centers. WHY did Toyota reorganize? HOW did Toyota perform for the reorganization? OUTCOMES of reorganization? Analysis and Conclusion

Ch. 2 Introduction Toyota Japan’s leading auto maker
A leader in adopting new organizational structures and processes both in Manufacturing Product development A benchmark for different industries Toyota’s type of organization was named as ” Heavyweight project management system”

Ch. 2 Introduction (Cont)
Toyota performed remarkably well with its project-centered organization during past several decades In recent years, all auto companies much more concerned with efficiency in new product development. Because of appreciation of yen and western competitors’ improvements, in the major markets, demand either slowed or declined. Toyota introduced the most radical changes in its product development organization to remain the leading position in auto industry Especially, during it adopted a strategy and structure specifically for multi-project management of product development

Ch. 2 Introduction (Cont)
The new organization features (Figure 3) Three vehicle development centers group similar projects together based on common platforms Fourth center provides common components to the different development centers Differs from Toyota’s former project centered organiazaion (Figure 1) Differs from traditional functional and matrix organizations

Ch. 2 Why did Toyota reorganize?
In Gereral why to make the changes for its product development groups around platform centers? Organizaional problems – Internal problems Changes in competitive environment – External problems

Ch. 2 Why did Toyota reorganize. (Cont)
Ch. 2 Why did Toyota reorganize? (Cont) Organizational Problems (1/2) Five major problems in former Toyota’s product development organization There were too many functional engineering divisions and too narrow a specialization of engineers. There were too many vehicle projects for each functional manager to manage the engineering details of each project as well as coordination across projects. It had become much more complicated and difficult for chief engineers to oversee all the engineering functions

Ch. 2 Why did Toyota reorganize? (Cont) Organizational Problems (2/2) The chief engineer organization did not foster coordination across projects Management did not sufficiently coordinate the RAD(Research & Advanced Development) group and individual vehicle projects

Ch. 2 Why did Toyota reorganize? (Cont) Changes in competitive environment The competitive environment surrounding Japanese automobile firms started changing around 1991. Rapid growth in production levels virtually ended. The importance of cost reduction became even more critical for international competition than before In addition to the appreciation of yen, Japanese advantages in development and manfacturing productivity were diminishing.

Ch. 2 Why did Toyota reorganize? (Cont)
A good engineering orgnization should be able to Create distinctive new products with new platforms and other innovative technology by project managers and engineers for the competitive reasons share technologies and coordinate different projects efficiently Thus, creating well-integrated new products and creating productis efficiently by leveraging existing technologies require a firm to be well organized to promote sharing. All above problems (interal & external ) and reasons indicates that it’s time for Toyota to reorganize.

Ch. 2 How did Toyota perform for the reorganization?
In General Six important features Reduction in the number of functional engineering division Reduction in the number of projects for each functional manager Changes in the roles of the center heads for multiple projects Establishment of planning divisions in each center Adoption of a hierarchical organization for chief engineers in related projects The new role of Center 4

Ch. 2 How did Toyota perform for the reorganization. (Cont)
Ch. 2 How did Toyota perform for the reorganization? (Cont) -- In General Not reduce total number of people working in product development, even rose 1991, Divided all its new product development projects into three development centers Center groups focus on the similarity in platform design. Center 1 is responsible for rear-wheel-drive platforms and vehicles; Center 2 for front-wheel-drive ones; Center 3 for utility vehicle/van ones. Toyota created Center 4 to devlop components and systems for all vehicle projects. by reorganized RAD (Research and Advanced development)

Ch. 2 How did Toyota perform for the reorganization? (Cont) Feature 1 Reduction in the number of functional engineering division By widening the engineering specialization within each division and by transferring some component development into Center 4, Toyota reduced the number of functional divisons in Centers 1-3. Toyota divided each function into three centers, the wider specialization did not require larger functional divisions.

Ch. 2 How did Toyota perform for the reorganization? (Cont) Feature 2 Reduction in the number of projects for each functional manager Each functional manager is responsible for a smaller number of projects in the new center organization. For example, managers in Center 1 can focus only on vehicle projects with rear-wheel-drive platforms. Before, in some functional areas, there used to be too many projects for functional managers to oversee, it was difficult for them to pay careful attention to all the projects.

Ch. 2 How did Toyota perform for the reorganization? (Cont) Feature 3 Changes in the roles of the center heads for multiple projects The center heads are supposed to play two important roles that have to be deliberately balanced. First, a center head helps each chief engineer integrate different functions. Second, each center head is responsible for the coordination of different vehicle projects within the center.

Ch. 2 How did Toyota perform for the reorganization? (Cont) Feature 4 Establishment of planning divisions in each center The management scope used to be so large in the old organization that the project portfolio planning and resource allocation for each project were too complicated to be effectively managed. Now the Planning Division in each center can consider technology sharing and resource allocation among multiple projects in the present and the future more carefully than before, by focusing on a limited number of closely related projects.

Ch. 2 How did Toyota perform for the reorganization? (Cont) Feature 5 Adoption of a hierarchical organization for chief engineers in related projects (Figure 5) Share same platform and driveline design differnt target customer segments and separate product concept need extensive coordination between two projects hierarchical chief engineer organization to achieve two goals in parallel for the projects achieve differentiation in product characteristics achieve integration in product development simultaneously

Ch. 2 How did Toyota perform for the reorganization? (Cont) Feature 6 The new role of Center 4 Most significant improvements regarding Center 4 was the introduction of a new organizational mechanism, called the cross-area system project. develop some new systems need new technical knowledge in multiple technical areas. (figure 6) In the old RAD Group, different technical areas usually worked separately and their coordination mechanism was not strong enough to deal with this type of project.

Ch. 2 Outcomes of reorgnization?
Because of the introduction of the center organization, Toyota achieved significant improvements in several areas. In particular, it simultaneously improved both cross-functional project integration and multi-project integration. Project integration through a streamlined structure Multi-Project Integration Within a Center

Ch. 2 Outcomes of reorgnization. (Cont)
Ch. 2 Outcomes of reorgnization? (Cont) -- Project integration through a streamlined structure The impact of the reorganization on reducing coordination tasks for chief engineers as they manage differeent functional groups

Ch. 2 Outcomes of reorgnization? (Cont) -- Project integration through a streamlined structure

Ch. 2 Outcomes of reorgnization? (Cont) -- Multi-Project Integration Within a Center The new organization strengthened the multi-project management perspective with the strong leadership of the center head and strong support from the center-oriented planning division. VS: before, because of the large number of vehicle projects, it was difficult to manage Toyota’s entire project portfolio and inter-project coordination. In order to achieve the integration within a center, to begin with, each center defines its own vision and theme for product development. Sharing a basic vision that focuses on projects within the center helps members effectively coordinate engineering activities.

Ch. 2 Analysis and Conclusion
Toyota has shifted from project-oriented management to multi-project management. One of the most important aspects of effective multi-project management is to improve both cross functional and inter-project integration at the same time.

Ch. 2 Analysis and Conclusion (Cont.)
However, there are some potential problems of the center system such as it is difficult to balance the chief engineer's autonomy and the center integration. there may be some problems regarding inter-center coordination. Although inter-center coordination could become the problem for Toyota, benefits from the inter-project integration within the center seem to surpass the potential problems at that point of time.

Chapter 3: Organizing Product Development in the World Auto Industry Introduction
Need for strategies, structures, and management systems for Individual circumstances, capabilities, and competitive objectives Framework for comparing basic organisational structures used in product development Nine major auto makers in Japan, United States, and Europe Smaller or less profitable firms have tended not to adopt Toyota-style development centers Some companies have introduced multi-project managers, modified conventional matrix-approaches, multi-product projects

Ch 3 Organizing Product Development in the World Auto Industry Introduction
Four types of product-development organizations in the auto industry Vary on size and scope of company’s product portfolio, and on functions that management centralizes or locates within projects Traditional Matrix Organization: different teams working on one or more projects simultaneously, permanent functional engineering departments: Renault(France), Mitsubishi (Japan), and Fiat (Europe) Product Team Organization: independent projects, one project at a time, multiple variations of a product, minimal barriers between functional departments: Chrysler (U.S.), and Honda (Japan) Semi-Center (Mazda, Nissan, GM)& Center (Toyota & Ford) Organizations: many product lines, share components, clusters of similar projects. Semi-center organizations include a matrix structure

Ch 3 Organizing Product Development in the World Auto Industry Introduction
Tendencies: largest firms use development centers or semi-centers smaller firms with production levels under 2 million vehicles use matrix organizations more variety of organisation types in medium-size firms (2-4 million) centers and semi-centers maybe uneconomical for small companies because of the duplication of engineering functions use of multi-product projects is common imitation influencing organisation structure matrix organization seems to become unwiendly if a firm has many projects active at the same time dedicated product teams, though they promote innovation, are not very economical if a firm has many similar products Grouping similar product models by development centers or semi-centers is useful way to simplify project management and promote component sharing

Project management ranging from middleweight to heavyweight
Ch 3 Organizing Product Development in the World Auto Industry Matrix Organization Prior to the mid 1980s Project management ranging from middleweight to heavyweight Strong functional departments More dedicated product teams Many firms have relatively few product lines Effort in optimizing product performance rather than ”cost-performance” Traditional Matrix Organisation: different teams working on one or more projects simultaneously, permanent functional engineering departments Renault(France), Mitsubishi (Japan), and Fiat (Europe)

Ch 3 Organizing Product Development in the World Auto Industry Matrix Organization - Renault
Conventional matrix, permanent and strong functional departments since 1989 Projects draw personnel from the engineering departments Departments contain smaller sections Project managers report to a senior executive and negotiate contracts with functional managers Engineers report to functional department managers and project management staff Renault tries to assign engineers to work only on one project, as in a dedicated team Technical Center opened in 1996: houses all the product development engineers Many engineers work on more than one project - differentieted matrix

Ch 3 Organizing Product Development in the World Auto Industry Matrix Organization - Renault
In 1990 established a small team to encourage learning - Group Delta of seven people Group worked with project managers and functional managers as a change agent, for better development methods such as heavyweight project management and more task overlapping Problems at Renault: lead times, costs, quality, and competitors Tried to improve quality by slowing development times, but this increased costs - no significant advantage Tries to reduce development time by task overlapping, working closely with suppliers, using more CAD/CAM systems, and increasing size of engineering teams Because Renault wants to produce hit products rather than compete with product lines, project teams are not interested in sharing platforms or components - difficult when considering platform sharing is more stable for a small firm Concurrent transfer technology could help to produce distinctive products but also to share platforms

Ch 3 Organizing Product Development in the World Auto Industry Matrix Organization

Ch 3 Organizing Product Development in the World Auto Industry Product Team Organizations and Multi-Project Management Engineers working on a product to a specific project more of less full time, atleast until they complete their main task Bring together all the engineers on a team Product team – best way to coordinate and integrate functional departments for a particular project Objective of multi-project management is to coordinate both across functional departments and across projects Important to manage effectively the functional groups that make up individual projects A firm should tackle the more complex process of coordinating groups across multiple projects Chrysler (U.S.) and Honda (Japan) are good examples of product team organisations as well as lean practices for managing individual projects Product Team Organisation: independent projects, one project at a time, multiple variations of a product, minimal barriers between functional departments

Ch 3 Organizing Product Development in the World Auto Industry Product Team Organizations and Multi-Project Management - Chrysler In 1989 abandoned its traditional matrix organization in favor of product teams - calls them platform teams Yet teams have not been so lean since continued to use several hundreds more engineers per project than comparable Japanese projects Involved major changes in product strategy, organizational structure, and work processes: Split its body design into two departments Divided these and other functional departments among five new platform teams: small cars, large cars, minivans, jeeps, and trucks Eliminated a central R&D department and decided to rely on the product teams to develop new technologies Independent product teams, new platform designs, and rapid introduction of multiple models based on common platforms have been a successful departure from sequential design transfer strategy and the old matrix organization

Ch 3 Organizing Product Development in the World Auto Industry Product Team Organizations and Multi-Project Management - Chrysler Chryslers relatively multi-stage projects resemble concurrent technology transfer because they try to build multiple products relatively quickly based on the same platform In 1991 established Chrysler Technology Center which colocated most platform team members on individual floors in one huge building Chrysler had a little need for multi-project management due to relatively few models Yet promoting sharing, which was considered important, company executives encouraged engineers to establish an informal organization of Tech Clubs - small groups of engineers from different platform teams working on similar components or problems The product team approach may not continue because of gradually increasing model lines

Ch 3 Organizing Product Development in the World Auto Industry Platform Team Organization

Ch 3 Organizing Product Development in the World Auto Industry Semi-Center Organization
Toyota’s influence on establishing development centers Group multiple projects around shared platforms Somewhere between matrix and center organizations Semi-Center Organisations (Mazda and Nissan (Japan), General Motors (GM in U.S): many product lines, share components, clusters of similar projects, duplicate some fuctional departments for groups of related projects, retain centralized functional departments that provide most of the components or engineering services to all projects, mix the centralized departments with clusters of projects, clusters include a matrix structure that break up some key functional departments just for the projecs grouped together, resembles the differentiated matrix

Ch 3 Organizing Product Development in the World Auto Industry Semi-Center Organization - Mazda
In 1993 abandoned its traditional matrix organization in favor of product development centers - established three, like Toyota Adopted also the name shusa for project managers Grouping of vehicles: recreational vehicles, higher-priced cars, and lower-priced cars - not a logical division from technical point of view Difficulties in achieving integration and standardization of components like Toyota achieves with its centers Mazda moved back to matrix in 1996 because: Unable to increase the number of product lines, managers found it difficult to separate technically related products into three separate groups - there was always overlap in components No sense in dividing groups when limited resources Integration with Ford - sharing platforms with Ford was more important than sharing components across Mazda projects Matrix easier to manage projects centrally and coordinate development work with Ford

Ch 3 Organizing Product Development in the World Auto Industry Center Organizations
Each center includes most engineering functions (Ford) Centers specislize in particular types of vehicles and design products for world markets (Toyota) Company executives want engineers to develop new products more frequently and quickly while lowering development costs (Toyota) Ford’s goals: to shorted lead time to design more vehicles in parallel from common platforms projects to reuse its 25 standardized modules in different product lines – important practice for effective multi-project sharing Center Organisations (Toyota & Ford) : many product lines, share components, clusters of similar projects, duplicate most fuctional departments for different clusters of projects

Ch 3 Organizing Product Development in the World Auto Industry Center Organization

Ch 3 Organizing Product Development in the World Auto Industry Comments
In 1990s managing individual development projects shows lean thinking Speeding up projects by overlapping phases and giving more authority to project managers, product teams, and suppliers Among firms that have moved beyond simple matrices or product teams to coordinate multiple projects, the most popular organizational innovation seems to be multi-project managers Multi-project managers exist in firms of center or semi-center organizations and managers for these Not many semi-centers because inherent disadvantages they do not simplify functional management as much as pure centers some functions within centers, but mostly outside centers creates very complex matrices ->debates over authority between functional dept managers and project managers

Ch 3 Organizing Product Development in the World Auto Industry Comments
A potential problem of development centers: how to minimize redundancy in enginering work Some redundancy is desirable to simplify the span of control for project managers and multi-project executives Though generally wanted to maximize scale or scope economies in engineering through centralized departments -> counter to the product teams Scale or scope economies can be difficult to achieve for center or semi-centers, unless firms adopt appropriate product grouping schemes and effective management techniques within the centers Desired independent projects with strong project managers Desired maximize chances for innovation and hit products Even multi-project organizations need to be flexible anough to handle these exeptional projects

Chapter 4: Strategies for Product Development and Multiple Projects
Studies of Product Strategy Categories Product Innovation Multi-Project Strategy Maps 4 Strategies Multi-Project Strategy Typology Comments

Ch 4 Studies of Product Strategy Categories (1/3)
Strategies of competitors –approach A company’s strategy based on how it relates to the strategies of competitors Three strategic types leaders rapid followers followers Companies can be successful only if they realize a low-cost position through superior development and production processes Approach is rather reactive than proactive, so it is not so useful for managers Key issue is implementation and how to be first to market

Past investments -approach Relationship between strategy and how a particular firm has accumulated capabilities in technology or organization from past activities or investments According to Johnson and Jones, focus is on ”technological newness” and ”market newness”

Multi-project management adheres more closely to this ”past investment” –approach Primary strategic issue: to what extent managers want to utilize the technology as well as other knowledge or capabilities already accumulated in past projects The concept of multi-project strategy and management requires a linkage between technology and organization It emphasizes the leveraging of accumulated firm level resources or capabilities

Ch 4 Product Innovation In the literature there is also another basic distinction in product strategy: Radical innovation Incremental innovation How new or old product is compared to a firm’s previous products and existing capabilities There are problems with current studies: The findings and the implications for managers are ambiguous E.g. in competitive markets leading firms need to be innovative, but they do not introduce radical innovations because they are successful in what they are doing Ability to compete effectively with incremental technology not prooven: purely technological competence is hard in long run

Ch 4 Product Innovation (cont.)
Some studies emphasizes the importance of producing incremental innovations in continuous streams In many cases firms have created radical innovations and then lost out to technological followers Companies have a better chance of succeeding if they develop products related in technology or markets to their previous product offerings To develop truely innovative products one needs to change its existing organizational processes, but to create incremental innovations one often needs to do no more than make key organizational processes routine

Ch 4 Product Innovation (cont..)
How to keep competitive edge? unlikely to remain competitive simply by following a strategy of incremental product innovation Not always necessary for companies to make distinction between radical and incremental product innovations Perhaps the best strategy is to develop highly innovative products very frequently, as long as these innovations does not alienate customers or take too long to find markets A strategic framework would allow a firm to take advantage of its existing organizational capabilities and acknowledge advantages and disadvantages

Ch 4 Multi-Project Strategy Maps (1/3)
A tool to visualize a company’s product strategy by mapping out patterns among several generations of products Can produces a picture of long-term product-development strategy Benefits: It illustrates a company’s product lines and their life cycles Shows the technological relationship among products

Ch 4 Multi-Project Strategy Maps (2/3) Example
Company A (Year) 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 utalization of existing platform from another model line or previous model in the same line

Ch 4 Multi-Project Strategy Maps (3/3)
In recent years, through effective multi-project strategies, various automobile companies around the world have been able to standardize platforms across number of products Common platform strategy makes it possible for firms to introduce a variety of new products cheaply and quickly, and respond speedily to new market trends These strategies can be transfered into other industries, such as software industry, as well

Ch 4 Strategies 1. Rapid expansion of the market for recreational vehicles
The rapid expansion of demand in different segments has created new opportunities for companies E.g. Recreational or sport-utility vehicles in the 1990s Some companies have developed new platforms as the basis for their recreational vehicle products For economic reasons most companies have reused existing passanger car platforms

Ch 4 Strategies 2. Intra-company platform standardization across brands
Reducing the number of platforms needed to support different brands has become a major strategic issue E.g. the PSA group has made considerable progress toward common platform with Citroen ZX (introduced in 1991) and used the same platform later in the Peugeot 306 (1993) E.g. Fiat introduced the Fiat Tipo in 1988 and then transferred that platform to the Lancia Dedra in 1989 and to Alfa Romeo 155 in 1992

Ch 4 Strategies 2. Intra-company platform standardization across brands (cont.)
Companies have faced several problems with differentiating the products that share the same platform Customers do not like paying more money for cars that are too similar in style and performance Brands may suffer if the same platform is offered also in other ”level of luxury” model E.g. Fiat Lancia is positioned as cheap and low luxury brand, but uses the same platform than Alfa Romeo, which is positioned as luxurious and sporty A company receive no cost savings if it wants to keep different brands separately by maintaining large number of unique components for each model E.g. Volkswagen brand vs. Audi brand

Ch 4 Strategies 3. International platform sharing
Sharing platforms across development groups in different parts of the world For example, in the mid-size segment, Ford used to offer the Sierra in Europe and the Tempo/Topaz in the US (different platforms), but introduced the Mondeo (successor to the Sierra) with a new platform, and then used this same platform to build the Contour/Mystique (successor to the Tempo) in the US.

Ch 4 Strategies 4. Platform sharing through alliances
In the past, companies with equity relationships have been sharing platforms E.g. Ford and its Japanese partner Mazda (Ford is the largest shareholder) Models, such as, the Mazda 323 (Familia) and Ford Escort share the same platform In recent years also companies with no equity relationships have been developing platforms in a joint projects E.g. Mitsubishi’s Charisma and Volvo S40/V40

Ch 4 Multi-Project Strategy Typology
Managers need a relatively sophisticated methodology to create a good multi-project strategic map The map should capture the technologial relationship among projects It should also allow managers to measure the impact of their strategy on market performance as well as on development costs for related products Typology is presented in the next two chapters Critical for strategic product development: the spesific application and timing of technology leveraging across multiple projects

Ch 4 Multi-Project Strategy Typology (cont.)
Application leveraging: A company can try to enhance the competitiveness of their original product (using existing technologies in a product redesign) A company can try to extend its investment to move into a new market segmentand achieve economies of scope in development Timing leveraging: The speed with which a company can exploit existing technologies is another critical factor that affects its competitiveness E.g. a project might try to borrow new components from another ongoing project that started earlier

Ch 4 Comments Emphasized points and issues:
Speed with which a firm can transfer component technologies from one project to another Strategic portfolio planning to organize the transfer of component technologies and efficiently utilize them in more than one product Allocation of engineering resources and the structuring of design work

Ch. 5 Multi-Project Strategies and Project Performance
In this chapter book examines the impact of four multi-project strategy types on lead time and engineering hours in new product development The examined data comes from a survey of 103 projects at 10 auto mobile firm in Japan and the United States Finding indicate that projects using the concurrent technology transfer strategy are the most efficient in terms of engineering hours

The reason is clear  only through concurrent technology transfer can a company reuse technology from a base project in another project, effectively share tasks among projects and make mutual adjustments and also conduct joint design work

Research decided to explore three propositions: Projects using the new design strategy should require the longest lead time and the most engineering hours because these projects build most components from the scratch and probably try to maximize innovations Concurrent technology transfer projects should require the fewest engineering hours and perhaps the shortest lead time because of task sharing and the ease of making adjustments in the designs The lead time and engineering hours for sequential technology transfer and design modifications should fall somewhere between new design and concurrent technology transfer projects

Organizational implications of concurrent transfer In this strategy engineers can transfer a design from a preceding base project to a new project more efficiently than in other strategies There are two basic reasons: 1. The time lag between completion of a base project and a new project 2. Overlap between a preceding base project and a new project These reasons can be broke down to five areas: 1. Advance planning 2. Mutual adjustments 3. Transfer of fresh versus dated designs 4. Problems of anonymous designs 5. The role of general manager for multi-project management

Advance Planning for Technology Transfer When a new project transfers a platform from a preceding project, the new project needs to adjust the base platform design to fit the new product’s individual architecture or specifications It’s more efficient for companies to make advanced plans during the base project for future reuse of a platform The time lag between a base project and a concurrent technology project is much shorter than between a base project and other transfer strategies Sequential transfer and design modification projects time lags are 66.6 and 81.2 months

Advance Planning for Technology Transfer These long time lags may indicate that a company designed a base platform without any plans to transfer it to future projects In only 33 percent of the sequential technology transfer and design modification projects had companies made a decision to reuse the platform before completing the base project It’s almost impossible to make accurate plans to modify the base platform for reuse in the new project when there is a long time lag between two projects

Mutual Adjustments, Task Sharing and Joint Design Because only concurrent technology transfer projects have significant overlap with a base project, only in this strategy can engineers designing components make mutual adjustments with the base project In addition, because of the overlapping and interactions, two linked projects also can share engineering tasks and project resources  this is called “task sharing” Engineers from two projects can jointly work on certain engineering tasks as a group, such as creating one brake system to go into two different products  this is called “joint design”

Mutual Adjustments, Task Sharing and Joint Design These three factors which only concurrent technology transfer projects can implement fully, may have contributed to the reduction in engineering hours Companies tend to develop the platform (the chassis, suspension system and other under-body components) in a joint team that includes engineers from a base project and the follow-on project Two projects create two separate groups to develop upper-body components  that’s because upper-body should be different for each product

Transfer of Fresh Designs Versus Dated Designs There are couple of fundamental problems with use of a dated platform design as a base in a new project following sequential technology transfer or design modifications Projects using an existing design as a base, developed mostly new components  this mixture may create some difficulties in linking the old platform with new components in other parts of the product The design requirements often change after they complete the original design, especially when the time lag between the completion of the base design and the transfer to a new project is long

Transfer of Fresh Designs Versus Dated Designs Requirement change is often made by non-technical reasons, these reasons include changes in perceived customer needs, market competition or governmental regulations These design changes tend to increase engineering hours in the sequential technology transfer projects because the modifications touch many different components

Problems of Anonymous Designs In sequential technology transfer or design modification projects companies usually transfer the design from base projects through drawings and written specifications This is because engineers may have completed the base project and started working on other products Therefore, engineers on the new project can have a hard time finding and communicating with engineers who worked on the old base platform These issues are important because face-to-face technology transfer can be much more efficient than transfer through specifications and drawings

Problems of Anonymous Designs In general, it’s difficult to transfer intangible or tacit understanding of design details without chronological overlap and direct interaction with engineers familiar with the original technology

Role of the General Manager for Multi-Project Management Companies with lots of technology transfers usually have general managers or vice-presidents responsible for product development above the project managers These executives are likely to oversee both a base project and a concurrent technology transfer project because the time lag between these projects is short Changes in executive leadership can clearly affect the efficiency of technology transfer between two projects

Role of the General Manager for Multi-Project Management A general manager is likely to consider the total productivity of the base project and the concurrent technology transfer project together In general, the shorter time lag between multiple interrelated projects, the greater the potential benefit of a strong general manager who can lead and manage multiple projects

Conclusion The efficiency of managing projects through concurrent technology transfer is somewhat analogous to the efficiency of managing overlaps among different functions within a single project Overlaps among multiple projects through concurrent technology transfer also enable a firm to avoid wasted or redundant work Managers can coordinate project objectives and engineers can adjust designs as they go along rather than rework designs later

Conclusion Researcher believe that the ability to overcome problems of concurrent engineering and task overlapping at least partially explains why concurrent technology transfer projects demonstrated such high levels of productivity Overlapping projects that share components creates significant interdependencies between these projects and makes it difficult to coordinate across projects as well as across interdependent functions

Conclusion Companies need to introduce specific organizational structures and processes that facilitate coordination across projects and functions as well as the process of mutual adjustments, task sharing and joint design

Ch 6 Multi-project Strategies and Company Performance

Ch 6 Outline Introduction Sales Growth and New Product Introductions
Research Data Analysis Conclusion

Ch 6 Introduction Companies are collections of projects -- on the point view of production development Efficient performance in individual projects, effective strategies for linking projects and creating a product portfolio will lead company with superior performance.

Ch 6 Introduction (Cont)
How multi-project strategies impact on company performance, in the book it is measured by market share and sales growth at all the world’s leading auto makers based on an analysis of 210 projects from 17 automobile manufactures. The analysis based on four strategy types (new design, concurrent technology transfer, sequential technology transfer and design modification)

Ch 6 Sales Growth and New Product Introductions (1/2)
Whether firms that introduce more new products than competitors actually increase sales more over time? Frequent product introductions have a positive influence on sales growth New product introduction rate is imported to measure the frequency of new products within each firm. measuring lingage across projects such as whether a platform is new or transferred measuring the speed of the transfer For industries, such as automobiles, freshness in styling and product functionality has a significant influnence on sales

Ch 6 Sales Growth and New Product Introductions (2/2)
Which type of multi-project strategy is the most appropriate to develop a large number of new products. Three proposition were explored: Firms that develop more products than their competitiors over the same time periods should have greater increases in market share and sales Firms that frequently follow the concurrent technology transger strategy should increase market share or slaes more than firms that do not follow this strategy so frequently. Firms that rely on design modifications primarily for new products should not increase their market share or sales as much as firms following the other three strategies

Ch 6 Research Data In General
Summary of performance and stratagy variables

Ch 6 Research Data (Cont) -- In General
17 largest passenger car manufactureres in the world 5 Japanese (Toyota, Nissan, Honda, Mazda, Mitsubishi) 3 U.S. (General Motors, Ford, chrysler) 9 Europe (W-Audi, M-Benz,BMW,Opel,Ford, etc.) 210 new car products into U.S. European and Japanese markets in Interviewed 130 engineers and 30 project managers Data was divided into four three-year time periods , , , 65 (data points) [= 17 firms x 4 time periods – 3 (no new product) ] describe company-level strategies and sales growth over a series of three-year periods

Ch 6 Research Data (Cont) -- Summary of performance and stratagy variables (1/4)
New Product Introduction Rate # of new products during a 3-year period, divided by # of product offerings in the beginning of the first year of the period. A new product includes all model variations developed within a single project. A new product has new interior and exterior styling. Additional variation projects such as new body types or styling are not counted as new products. "Special off-line" products are not counted as new products

Average Platform Design Age (years) An average of platform design ages for all new products introduced during a 3-year period. The platform design age is defined as time passed since a platform each new product uses was originally developed and introduced Usage of Multi-project strategies (in percentage) # of new products using each multi-project strategy during a 3-year period, divided by the total number of new products introduced during the 3-year period.

Multi-project strategy New Design New products that develop a new platform. Concurrent Technology (Rapid Design) Transfer New products that use a platform a project for a separate product line originally developed. Transfer occurs within 2 years of the introduction of the product that originally develops the platform. Sequential Technology Transfer New products that use a platform a project for a separate product line originally developed. Transfer occurs at least 2 years after the introduction of the base product. Design Modification New products that use a platform a predecessor (an earlier generation) of the same product line originally developed.

Market Share Change (percentage) Percentage change in market share (revenue in $) from the beginning of each three-year period to the end of the period.

Ch 6 Analysis Various analysis from different perspectives to examine the impact of different multi-porject strategies on market performance. Following are two of anaylsis samples based on the reasearch data and variables 17 firms over four three-year periods 65 data points measuring by 5 variables four different multi-project strategies new product introduction rate

Ch 6 Analysis (Cont) -- Sample 1

Figure 4 shows total number of new product introductions increased rapidly after 1989 50 ( )  61 ( ) use of the rapid design transfer strategy also increased sharply in the middle of 1980s 6% ( ) 20%( ) & 18%( ) This trend implies the speed of new product development has been accelerating during this period firms have been transferring new platform designs more quickly to other product lines throughout the period

Table 4 shows Firms in Group 2,which used the rapid design transfer strategy most extensively among the four strategic groups. Used new desgin strategy in 46% of their new products during the 3 year period. They developed more new products with relatively new average platform designs Gained the largest market share 23% during the 3-year period.

Ch 6 Conclusion In order to increase market share, it seems essential for firms to develop new designs and at the same time leverage these new designs quickly in other products rather than only developing a new design or transferring a design slowly to other projects. The speed with which new technologies are leveraged across multiple projects or products within the firm at least partially determines corporate-level market performance in the form of revenue growth.

Ch 6 Conclusion (Cont) Firms need to expand their scope in new product strategy to consider the effective multi-project strategy. Otherwise, as long as firms focus on individual projects for a product line, either new design or design modification strategies are not as effective as rapid design transfer strategy for market share growth for the entire firm. The rapid design transfer (concurrent technology transfer ) strategy is actually more efficient organizationally than sequential design transfer or design modification strategies, because Only through rapid design transfer can a preceding design be transferred from a base project to a new project with effective task sharing among engineers and mutual adjustments between the two projects.

Ch 6 Conclusion (Cont) Variables used here to predict market performance have limitations. for example: Sales growth should result from the ability of a firm to design and build products that customers want to buy, and this relates to quality, price performance, advertising, product availability, service, and numerous other factors. The effective management of multiple projects organizationally may also get problems for example: it is argued that heavyweight project manager system and relatively autonomous project team approach are important for an individual project performance.

Chapter 7. Organizational Requirements for Multi-Project Management
Overview Functional vs. Project-Centered Organizations Organizational Requirements for Multiple Projects Communication and Coordination mechanisms Multi-Project Management Through Matrix Management Knowledge Retention and Transfer Mechanisms

Ch 7 Overview Organizational Requirements for Multi-Project Management
In order to manage multiple projects well, companies need: Specific organizational capabilities that promote coordination Communication across functions as well as across projects ”Cross-functional” management Brings together engineers and staff from different functional areas to form multi-disciplinary teams Helps components groups and functional departments communicate better, share knowledge more easily and establish common goals Concurrent engineering and lean product development encourage Overlapping activities helps engineers speed up development and solve various problems simultaneously

Ch 7 Overview (cont.) Organizational Requirements for Multi-Project Management
Cross-functional teams and concurrent engineering have led to more effective management of individual projects Managers need to coordinate multiple projects in order to achieve optimal efficiency and effectiveness from the perspective of the corporation as a whole To manage managers need to understand the organizational capabilities and processes that this way of thinking requires

Ch 7 Functional vs. Project-Centered Organizations
Project-centered organizations and their advantages: They help break down walls between functional departments and bring different departments together toward a common product concept (e.g. luxurious economy car) and common goals (e.g. shorter lead time or lower costs) Engineers from different specialties might combine to make product development more innovative (for example, Sony’s CD Walkman, where electronic, mechanical and laser engineers cooperated in a joint project)

Ch 7 Functional vs. Project-Centered Organizations (cont.)
Functional organizations and their advantages: More tight and intensive group that stay together – whereas project groups forms and disbands members every time they complete a product Functional organizations has a better position to produce radical innovations in particular technologies or be state-of-the-art in selected areas For example, they may produce the best component desing and performance, possibly at the expense of total product integrity (some customers will want this type of excellence, like CR players with the longest battery life)

Ch 7 Functional vs. Project-Centered Organizations Matrix structure
We saw in the case of Toyota and other car makers that companies tend to introduce matrix structures These matrix structures combine functional departments and cross-functional product teams in the form of projects Projects within a matrix structure usually succeed in integrating across functions while maintaining some functional expertise within the organization

Ch 7 Functional vs. Project-Centered Organizations Matrix structure (cont.)
A matrix that combines projects with functional departments may obtain some of the advantages of both approaches, but it also creates particular problems: Level of authority held by the project manager as opposed to the functional department managers Disagreement on how to solve the problems Who will deside (functional manager, project manager or senior manager?) Responsibilities and physical location of engineers Should an engineer be responsible for a particular technology and remain with a functional group or should he / she be member of a project team and co-locate all in same place These problems are strategic, not just simply organizational: Do managers want to optimize a particular technology or maximize the chances of innovation?

Ch 7 Functional vs. Project-Centered Organizations Conditions determine organization
3 conditions determine whether a project-centered or a functional organization is more appropriate: The rate of technological change The length of the development project The degree of interdependency among the functional components being developed for the product In case of rapid technological change, there is a high chance that engineers involved a project will become detached from information on the latest advances in their field If the project takes a long time (even though the pace of change is not rapid) engineers are likely to fall behind the state of the art in their field

Ch 7 Functional vs. Project-Centered Organizations Conditions determine organization (cont.)
Functional organizations help a firm’s long-term competitiveness because they do not pursue the short-term goals If there are few interdependencies among the functional components in a product, then there is little need for a project-centered organization On the other hand, if the engineer cannot design good components without interacting extensively with engineers making other components because of significant technical interdependencies, then a project-centered organization is most suitable

Ch 7 Organizational Requirements for Multiple Projects
Functional organization seems to be better in effective management of multiple projects than project-centered organization, because functional managers generally have more authority E.g. If a major objective is to lower costs  Through functional organization we have ability to standardize components across multiple products  reduction in task duplication A key benefit of project-centered organizations is the ability to create differentiated products with an integrated or cross-functional management style Share technologies and knowledge across multiple product lines and projects

Ch 7 Organizational Requirements for Multiple Projects (cont.)
Integration across departments is especially important because of the potential impact it has on the speed of a project Design changes during a project come from interference problems between sub-system components (and usually causes schedule delays) In order to reduce these problems, utilize both cross-functional and project-centered management

Ch 7 Organizational Requirements for Multiple Projects (cont..)
Multi-project management is a way to manage multiple product lines without resorting to the disadvantages of a purely functional structure Objective is to share as many components among different product lines as makes sense This cannot be done easily with functional organizations For effective multi-project management, both cross-functional integration and cross-project integration are necessary

Ch 7 Organizational Requirements for Multiple Projects (cont...)
The diagram illustrates multi-project organization and how it differs from a functional organization To integrate across one or more projects, multi-project management requires: A level of control above the project manager that coordinates different projects Individual functional departments and individual engineers Multi-Project Management (Mgmt) Project (Cross-Functional) Mgmt Functional Mgmt Individual Mgmt

Ch 7 Communication and Coordination Mechanisms
In order to utilize concurrent technology transfer, project managers and engineers have to Communicate well Coordinate their work properly If insufficient communication occurs, then functional managers and engineers are not able to adjust their activities to the requirements of multiple projects Because the communication has such a important role, only strong project managers can effectively manage cross-functional interactions caused by such interdependencies Even the component-level interactions between multiple projects may require project-level or system-level coordination when components are parts of sub-systems and interdependency occurs

Ch 7 Communication and Coordination Mechanisms (cont.)
Project managers for concurrent technology transfer need to spend time on coordination with other projects through meetings with other project managers In car industry companies used 4 different organizational mechanisms to coordinate multiple projects: Mutual coordination among the project managers, such as through meetings Coordination by executives who supervise the project managers Coordination of multiple projects by functional department managers Direct mutual coordination among the individual engineers working on each separate projects

Ch 7 Communication and Coordination Mechanisms Inter-Project Coordination Mechanisms
General Manager Project Manager Functional Manager Engineer In the survey of project managers founded out that direct coordination among the project managers is the most effective mechanism, followed by coordination through supervision of the project managers Direct coordination between project managers Coordination by general managers Coordination by functional managers Direct coordination between engineers 3 1 4 2

Ch 7 Multi-Project Management Through Matrix Management
There are two mechanisms that companies are using to move beyond simply trying to balance a functional and a project-oriented structure The differentiated matrix The dual responsibility system for engineers These organizational innovations have become more common since the early 1990s

Ch 7 The Differentiated Matrix and Component Characteristics
The differentiated matrix provides a balance that minimizes the conventional trade-offs between a functional vs. a project-oriented structure It allows functional groups to focus on components that management wants to standardize across multiple projects It allows also projects to create distinctive products by creating separate groups for those components that makes the real differentiation in the eyes of customer To make the differentiated matrix structure work, a company needs to have a strategy for creating sub-systems and then for sharing these across products Organizing and coordinating these to different groups and project teams are also needed

Ch 7 The Differentiated Matrix and Component Characteristics Framework
A framework for analyzing technical requirements and then creating different types of component groups First step: Clarify what is necessary to coordinate among functional departments as well as among projects Second step: Form different component development groups, which we have divided into four types as we can see from the framework Needed Different sub-systems Common sub-systems Product Group Multi-project Component Group Coordination Among Functional Departm. Different individual components Standard components

Ch 7 The Differentiated Matrix and Component Characteristics Framework
Examples to illustrate the framework: Standard sub-systems: Audio equipment Can be common across multiple products They do not require much coordination across groups (engineers ”buy” these parts through basic specifications) Multi-project groups: Automobile platforms Sub-systems that require high levels of coordination amond different engineering groups but management wants different projects to share them Product groups: Microsoft (MS) Office Three major sub-systems (Excel, Word and PowerPoint) Product groups share about half of their components E.g. Word group has the most experience with text processing and file management, so MS management has decided that the Word group should build these modules for all the applications groups One group take the lead: this will clear responsibilities and deciding the design requirements for the common component

Ch 7 Dual Responsibility System for Engineers
The differentiated matrix  Coordination among different functions or component groups  But does not address the issue of coordinating engineers across different functional departments and projects Problem is whether to control engineers through the functional department structure or through the project structure

Ch 7 Dual Responsibility System for Engineers Example
Components development a b c d e f g h i j k 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 X X Project A Engineer X X X X Project B X X Project C X X X Project D

Ch 7 Dual Responsibility System for Engineers Example (cont.)
As we can see from the figure, there are 4 projects and 20 engineers working for the project In this example individual engineers take on coordination responsibilities for specific components Individuals make sure that different groups share the appropriate information regarding the specific components Engineers that are working on the other projects are responsible for giving technical information and specifications to the responsible component engineer

Ch 7 Knowledge Retention and Transfer Mechanisms
According to Aoshima, there are 2 types of knowledge: ”Local” knowledge Related to the development of specific components E.g. engine or brake ”System” or ”Integrative” knowledge Related to integration of different components Archival-based mechanisms, such as documents, reports etc., are more effective in promoting knowledge retention than individual-based mechanisms such as transfer of people or direct connection This is because component-level knowledge is specialized and possible to write down

Ch 7 Knowledge Retention and Transfer Mechanisms (cont.)
”Integrative” knowledge This type of knowledge needs individual-based mechanisms, primarily face-to-face communication and transfer of people Difficult to communicate and write down Integration requires knowledge of many different areas Findings for multi-project management To implement technology transfer, firms should overlap projects so that engineers can communicate and solve design problems face-to-face Important to keep people together because complex products require different type of knowledge, some of which is hard to learn and transfer to new people

Ch 7 Product Variety and Manufacturing
Important In multi-project management The manufacturing is flexible The manufacturing supports platform families and product variations Companies have many strategies to overcome the potential negative impact of product variety on manufacturing performance: Products designed to share subsystems Subsystems designed to share modules Low-inventory production techniques Parallel assembly etc.

Ch. 8 Implications and Lessons for Managers
Managers are better off if they leverage investments in new technology as opposed to not leveraging these investments at all Leverage of investments should happen quickly across markets (as in concurrent technology transfer) rather than slowly across time (as in sequential technology transfer) Toyota and other firms have explicitly adopted multi-project management systems that work  they have evolved beyond traditional functional, matrix or single-project organizations

Ch. 8 Implications and Lessons for Managers Lessons from Toyota and others
It’s important to improve integration across different engineering functions as well as across different projects simultaneously  Toyota provides an excellent sample of how to do this Its center organization facilitates coordination among technically related projects Toyota has improved integration across functions by strengthening the authority of project managers over functional management Toyota streamlined tasks for integrating across functional groups in order to make it easier to integrate multiple projects As people stay together in multiple product generations, consistent design philosophy can be learned and carried out from project to project Competition in performance among centers promotes learning, improvement, efficiency, and innovation

Ch. 8 Implications and Lessons for Managers Lessons from Toyota and others
Grouping related projects is not so effective without introducing a logic for grouping projects and then supporting mechanism and processes for multi-project management Grouping according to market similarities or to technical similarities - the latter is recommended Problems in grouping products, especially in semi-centers: what to leave out and how many centers to establish Explicitly establish management positions before grouping Insufficient thought and analysis of goals and problems before a fundamental reorganization can lead firms to make too frequent organizational changes

Ch. 8 Implications and Lessons for Managers Why concurrent technology transfer
Firms that follow concurrent technology transfer appear to grow more quickly than competitors who develop products one at a time or sequentially transfer platforms to other projects Firms do better if they leverage key components across multiple product lines while technology is still relatively new There are also several reasons why firms might not to try concurrent technology transfer: Some firms want to maximize product innovation or product integrity in every project - fear on compromises There is some danger in transferring technologies not proven in the marketplace or in transferring designs that may have some flaws Concurrent technology transfer places too heavy burden on company planners for new product - fear of long-time plans

Ch. 8 Implications and Lessons for Managers Why concurrent technology transfer
More of why firms might not to try concurrent technology transfer: Concurrent technology transfer complicates project management due to increased interdependencies among projects Managers fear that companies relying heavily on suppliers could face an additional complicating factor in coordinating multiple projects Some managers and engineers prefer to invent their own technologies rather than rely on outside sources, even within the same company Some managers simply want to expand the size of a single project to accommodate multiple distinct products, rather than have a separate base project and a follow-up project relying on concurrent technology transfer

Ch. 8 Implications and Lessons for Managers Applicability of multi-project management
Even though a company has only one product it is important to that managers and engineers still think about transferring technology or specific components across different product generations This sequential transfer over time is also a form of multi-project management Multi-project management addresses the future when expanding the product lines when introducing new technologies into existing products

Breadth of Target Market Segments Size of Target Market Segments
Ch. 8 Implications and Lessons for Managers Applicability of multi-project management The Framework Relevant Area for Multi-project Management Diversified Breadth of Target Market Segments Focused Niche Markets Mass Markets Size of Target Market Segments

Ch. 8 Implications and Lessons for Managers Applicability of multi-project management
The book also introduces a framework for thinking about when it is appropriate to adopt multi-project management The framework compares the breadth of a firm’s target market segments and size of the target segments Multi-project management is most appropriate in mass-market and / or diversified markets Project structures are not particularly good at fostering radical innovation in particular areas because they do not promote deep technical excellence or specialization Here permanent functional departments are better Continuity in department membership and technical knowledge is somewhat lost in project structures

Ch. 8 Implications and Lessons for Managers Final Thoughts
Fundamentally, companies need to decide if they want to think and manage in a multi-project mode There are numerous ways to manage and focus business in this industry: one can decide to produce hit poducts one at a time or they can manage projects as part of a portfolio etc. Multi-project management requires integrating across engineering functions that cut across multiple projects These activities require more long-term planning and more frequent communication among project members

Qian Wang Sanna Teiskonen Heikki Paananen Jani Liimatainen

Similar presentations

Presentation on theme: "Qian Wang Sanna Teiskonen Heikki Paananen Jani Liimatainen"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Qian Wang Sanna Teiskonen Heikki Paananen Jani Liimatainen

Similar presentations

Presentation on theme: "Qian Wang Sanna Teiskonen Heikki Paananen Jani Liimatainen"— Presentation transcript:

Similar presentations

About project

Feedback