SB Program University of Jyväskylä Thinking Beyond Lean How Multi-Project Management is...

SBProgram

University of Jyväskylä

Thinking Beyond LeanHow Multi-Project Management is Transforming Product

Development at Toyota and Other Companies(Cusumano, M. A. & Nobeoka, K. 1998)

Qian WangSanna TeiskonenHeikki PaananenJani Liimatainen

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


Outline




SBProgram


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

SBProgram



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

SBProgram



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

develop

SBProgram



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

SBProgram



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?

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram


Outline




SBProgram


Ch. 2 Case studyReorganizing for Multi-Project Management

Toyota’s New Structure of Product Development Centers

SBProgram


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

SBProgram


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”

SBProgram


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 1992-1993 it adopted a strategy and structure specifically for multi-project management of product development

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram



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

SBProgram



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

SBProgram



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.

SBProgram


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

SBProgram


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)

SBProgram


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.

SBProgram



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.

SBProgram



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.

SBProgram



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.

SBProgram



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

SBProgram


SBProgram



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.

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


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.

SBProgram


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.

SBProgram


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.

SBProgram


Outline




SBProgram


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

SBProgram


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

SBProgram



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

SBProgram



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)

SBProgram



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

SBProgram



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

SBProgram


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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



Platform Team Organization

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



Center Organization

SBProgram



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

SBProgram



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

SBProgram


Outline




SBProgram


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

SBProgram


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

SBProgram



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”

SBProgram



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

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


Ch 4 Multi-Project Strategy Maps (2/3) Example

Company A

79 80 81 82 83 84 85 86 87 88 89 90 91 92 93

(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

SBProgram


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

SBProgram


Ch 4 Strategies1. 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

SBProgram


Ch 4 Strategies2. 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

SBProgram


Ch 4 Strategies2. Intra-company platform standardization across brands (cont.)

Companies have faced several problems with differentiating the products that share the same platform1. 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

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

SBProgram


Ch 4 Strategies3. 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.

SBProgram


Ch 4 Strategies4. 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

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


Outline




SBProgram


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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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”

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram



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

SBProgram


Outline




SBProgram


Ch 6 Multi-project Strategies and Company Performance

SBProgram


Ch 6 Outline

Introduction Sales Growth and New Product Introductions Research Data Analysis Conclusion

SBProgram


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.

SBProgram


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)

SBProgram


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

SBProgram


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

SBProgram


Ch 6 Research Data

In General Summary of performance and stratagy variables

SBProgram


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 1980-1991

Interviewed 130 engineers and 30 project managers Data was divided into four three-year time periods

– 1980-1982, 1983-1985, 1986-1988, 1989-1991 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

SBProgram


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

SBProgram



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.

SBProgram


Ch 6 Research Data (Cont) -- Summary of performance and stratagy variables (3/4) 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.

SBProgram



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.

SBProgram


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

SBProgram


Ch 6 Analysis (Cont) -- Sample 1

SBProgram



Figure 4 shows– total number of new product introductions increased rapidly after 1989

• 50 (1986-88) 61 (1989-91)

– use of the rapid design transfer strategy also increased sharply in the middle of 1980s

• 6% (1983-85) 20%(1986-88) & 18%(1989-91)

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

SBProgram



SBProgram



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.

SBProgram


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.

SBProgram


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.

SBProgram


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.

SBProgram


Outline




SBProgram


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

SBProgram


Ch 7 OverviewOrganizational 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

SBProgram


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

SBProgram


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)

SBProgram


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)

SBProgram


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

SBProgram


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?

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


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

SBProgram


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:1. Mutual coordination among the project managers, such as

through meetings2. Coordination by executives who supervise the project managers3. Coordination of multiple projects by functional department

managers4. Direct mutual coordination among the individual engineers

working on each separate projects

SBProgram


Ch 7 Communication and Coordination Mechanisms Inter-Project Coordination Mechanisms

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

1. Direct coordination between project managers

2. Coordination by general managers

3. Coordination by functional managers

4. Direct coordination between engineers

12

3

4

General Manager

Project Manager

Functional Manager

Engineer

SBProgram


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

SBProgram


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

SBProgram


Ch 7 The Differentiated Matrix and Component CharacteristicsFramework

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

NotNeeded

NeededNot NeededCoordination Among Projects

ComponentGroup

Different sub-systems Common sub-systems

Different individualcomponents

Standard components

Needed

Coordination AmongFunctional Departm.

ProductGroup

Multi-projectComponentGroup

SBProgram


Ch 7 The Differentiated Matrix and Component CharacteristicsFramework

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

SBProgram


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

SBProgram


Ch 7 Dual Responsibility System for EngineersExample

Project A

Project B

Project C

Project D

Engineer

1 2 3 4 5 6 7 8 91011121314151617181920

XX

X

X

X

X

X

a b c d e f g h i j k

XX

X

Components development

X

SBProgram


Ch 7 Dual Responsibility System for EngineersExample (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

SBProgram


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 ”Local” knowledge

– 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

SBProgram


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

SBProgram


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.

SBProgram


Outline




SBProgram


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

SBProgram


Ch. 8 Implications and Lessons for ManagersLessons 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

SBProgram


Ch. 8 Implications and Lessons for ManagersLessons 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

SBProgram


Ch. 8 Implications and Lessons for ManagersWhy 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

SBProgram


Ch. 8 Implications and Lessons for ManagersWhy 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

SBProgram


Ch. 8 Implications and Lessons for ManagersApplicability 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

SBProgram


Ch. 8 Implications and Lessons for ManagersApplicability of multi-project managementThe Framework

Relevant Area for Multi-project Management

Niche Markets

Mass Markets

Size of Target Market Segments

Diversified

Focused

Bre

adth

of

Tar

get

M

arke

t S

egm

ents

SBProgram


Ch. 8 Implications and Lessons for ManagersApplicability 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

SBProgram


Ch. 8 Implications and Lessons for ManagersFinal 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

Date post:	21-Dec-2015
Category:	Documents
View:	224 times
Download:	0 times

SB Program University of Jyväskylä Thinking Beyond Lean How Multi-Project Management is...

Documents