Innovation and project development: an impossible equation? Lessons from an innovative automobile project development Franck Aggeri and Blanche Segrestin Ecole des Mines de Paris, 60 Boulevard Saint Michel, 75272 Paris cedex 06, France.
[email protected];
[email protected]
Product development performance has become a key issue for car manufacturers. But innovation seeks to outperform dominant design, whereas project development targets welldefined areas (costs, lead times, quality, etc.). This article provides an analysis of the extent to which innovation is compatible with recent managerial and technical methods (project and multi-project management, co-development, simulation tools and digital mock-ups, etc.). The analysis is based on a recent development project conducted at Renault in which these various techniques were used in an attempt to achieve highly ambitious targets simultaneously in the areas of lead times, costs and innovation. During the course of the project, unexpected design problems revealed failures in co-ordination, monitoring procedures and expertise. We argue that recent project development methods can induce negative effects on collective learning processes and that these effects have managerial implications for innovative developments.
1. Introduction
I
n recent years, innovation has, for most firms, become a key issue in an economic context in which competition is increasingly driven by high rates of product renewal. It is possible that the managerial impact of this state of affairs has been underestimated. Car manufacturers have been working for many years now on ways of developing new and singular products. However, innovation seeks to outperform dominant design, whereas project development targets well-defined areas in which to improve performance (costs, lead times, quality, etc.). According to the literature on the subject, innovation consists in diverging processes that explore new alternatives,
values and performance criteria, whereas product development consists in converging processes built around predefined targets and deadlines (Van de Ven, 1986; March, 1991; Van de Ven et al., 1999). How can the characteristics of innovation and project development be successfully combined? The question is all the more critical that design activities are becoming increasingly rationalized: following the wave of total quality, partnerships and heavyweight project managers (Womack et al., 1990; Clark and Wheelwright, 1992), simultaneous engineering with cross-functional teams has now been introduced (Midler, 1993). Car manufacturers have adopted more up-to-date approaches, integrating suppliers into the produc-
R&D Management 37, 1, 2007. r 2007 The Authors. Journal compilation r 2007 Blackwell Publishing Ltd, 9600 Garsington Road, Oxford, OX4 2DQ, UK and 350 Main St, Malden, MA, 02148, USA
37
Franck Aggeri and Blanche Segrestin tion process much earlier than was previously the case, and introducing digital tools (simulation devices and digital mock-ups) in order to solve problems much earlier, thereby reducing lead times (Fujimoto and Thomke, 2000). Firms have also introduced multi-project management to achieve economies of scale, while still designing singular and innovative products (Cusumano and Nobeoka, 1998).1 To what extent do these new approaches make it possible to combine innovation with project targets? Conversely, what is the potential impact of project management techniques on possible innovations? The study of a recent automotive development project may provide a number of insights into these issues. The Renault Laguna II project, launched in October 2001, was both ambitious and innovative. It required not only an acute and rigorous approach to project development but also tremendous innovative capabilities. The project combined all the approaches described above to dramatically improve performances in terms of lead times, costs and innovation. Compared with previous projects, the Laguna II represented an authentic leap forward. However, despite its commercial success, the project ran into major and unexpected difficulties during the development stage. Indeed, the company was forced to delay the launch of the vehicle by 6 months. However, the problems encountered in the Laguna II project are of interest in that they shed light on the degree to which innovation and project development organization overlap or, indeed, fail to overlap. We were able to study the Laguna II project during the last 18 months of its history. Thus, by analysing a number of ‘design problems’, we mapped the ‘journey’ of the development project (Van de Ven et al., 1999) in order to explain why the company failed to achieve all its targets. The design problems were especially concentrated in an area (the doors) in which so-called incremental and ‘process’ innovations had been introduced. Whereas most recent managerial techniques have, to a large extent, been developed to detect and solve problems as soon as possible, these techniques failed to enable the anticipation of critical issues in the doors development. We will argue that these techniques are efficient when problems can be apprehended by existing knowledge and when experts know how to deal with them. Yet, when the design problems are encountered for the first time and when knowledge is not available to estimate their potential effects, these techniques may hinder the needed learning processes. 38
R&D Management 37, 1, 2007
The article is structured as follows: in the first section, we stress the importance of ‘early problem-finding and solving’ for product development performance, and reappraise recent development methodologies as a means of fostering ‘front-loading strategy’. In the second section, we analyse the case of the Laguna II project and explain the problems encountered with the vehicle’s doors, an area in which process innovations were introduced. We argue that the collective learning processes required for the successful implementation of innovative features were severely hindered. In the third section, we discuss the shortcomings of recent managerial approaches to innovation management. We then deliver our conclusions.
2. Front loading strategy as a means of improving project development Cars are probably the most complex of all mass-produced industrial products. No other mass-produced item combines so many different components and technologies, has such draconian requirements in terms of safety, the environment, acoustics and aesthetics or requires such high levels of performance. Automotive development cycles generally last between 3 and 4 years and involve hundreds of engineers, technicians and partners (Moisdon and Weil, 1996). Design teams have to resolve seemingly endless problems in order to meet requirements. In this respect, Fujimoto and Thomke (2000) define the product development process as ‘a bundle of interdependent problemsolving’, with each problem-solving process consisting ‘of design, build, run and analysis activities’. From this point of view, the reduction in lead times and costs depends on early problem-finding and solving. The later the problems are discovered and solved, the greater the cost of their solution and the higher the risk of falling behind schedule. This is particularly true when companies start to make investments in production processes (plant equipment, tools, etc.). From that moment on, any ‘modifications’ in product design or product processes are likely to generate additional costs. Furthermore, such modifications may have unpredictable effects on the development of adjacent components. This makes it easier to understand why one of the primary objectives of car manufacturers is to ensure that modifications are kept to a minimum. Various approaches are implemented to deal with design problems. r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
Innovation and project development
2.1. Front-loading strategies According to Fujimoto and Thomke, early problem-solving requires ‘a strategy that seeks to improve the development performance by shifting the identification and solving of design problems to earlier phases of the product development process’, a strategy that the authors call ‘frontloading’. The main rationalizations in car development can be understood in this perspective: Cross-functional integration: Simultaneous engineering (cross-functional teams and the overlapping of development phases) and project management are used to avoid the kind of late and costly design problems that arise in sequential development (Clark and Fujimoto, 1991; Lundin and Midler, 1998). Contractual relationships and partners’ commitments: Car manufacturers have formed new partnerships with external suppliers in order that these last assume greater responsibilities. In old-style contracts, any design changes were billed to the car manufacturer. In the new fixed budget contracts, suppliers bear modification costs; as a result, it is in their interest to signal any problems they encounter as early as possible. Some authors have analysed how this practice has substantially reduced the number and cost of design modifications (Garel and Midler, 1998, 2001). The introduction of internal contracts into project management has also encouraged designers to identify technical risks in the early stages of the project and in so doing to anticipate a certain number of recurrent problems (Nakhla and Soler, 1998). From carry-over to modularity: Multi-project approaches can also be analysed in this perspective of rationalization. Such approaches make economies of scale possible by standardizing components and sharing engineering resources. In multi-project approaches, one can either carry over already validated components and platforms, or adopt a modular system, where design can be applied in modules that are both parallel and separate. The carry-over should cut lead times by reducing the number of new problems. However, modular systems have been shown to be very effective in that the integrity of the overall system is preserved thanks to architectural interfaces and design rules (Baldwin and Clark, 2000). r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
Modelling and testing: Lastly, digital validation systems, simulation and mock-up tools now make it possible to speed up the detection of design problems. Whereas design teams used to have to wait for physical prototypes before being able to carry out definitive design validations, they are now able to define problems and validate alternative solutions at a much earlier stage (Fujimoto and Thomke, 2000; Thomke, 2003). As in the software industries, early deliveries of prototypes can also stimulate interactions with users to define product specifications more effectively (MacCormack, 2001).
2.2. Design problem typology It is now generally recognized that these approaches contribute to early problem-solving. Yet, what are the design issues they can handle? Design problems are highly heterogeneous and their impact on development projects is not uniform. They may involve varying degrees of difficulty, costs and time. It is one thing to isolate possible problems, but quite another to actually solve them. Let us introduce a framework enabling us to distinguish between various types of design problems. The sooner the problems are detected, the better it is. But detection does not necessarily mean action. Once problems are detected, thanks to the new approaches described above, only part of the job is done. Besides, as designers are generally overloaded with work, they may prefer to put certain issues on the backburner. We will, therefore, introduce two variables to account for design problem strategies. The first variable is the latency period: This period consists in the time-lag between the date of detection of a problem (when some signals, e.g. a negative test or an expert opinion, indicate a problem) and the date on which it is effectively and collectively taken into account by designers. The period can last several months, as designers have a tendency to deal initially with problems to which they already know the answers. Problems with which they are less familiar tend to be left aside for a while. The second variable is the length of time required to actually solve problems: Once a problem has been collectively broached, there is no knowing how long it will take before it is R&D Management 37, 1, 2007
39
Franck Aggeri and Blanche Segrestin effectively resolved. In the simplest cases, only a short amount of time is required. The most difficult cases, however, involve numerous shot-in-the-dark-style attempts at problemsolving. This can necessitate several designvalidation cycles, a process that is inevitably very time-consuming and, as such, more than likely to impact negatively on the overall schedule of the project. The following typology can be derived from this scenario (Figure 1): The first category of problems (Box 1) appears to be the easiest to resolve. Indeed, such problems tend to be the ones that crop up most frequently. They are rapidly addressed and solutions are quickly found. For instance, one designer asks another to move a cable a short distance: only minor adjustments are required and they can be made rapidly. Box 2 is more paradoxical. Design problems of this type are addressed long after they are first detected even though they are easy to solve. Why should this be so? The answer to this question lies in the fact that many adjacent components may be modified during the development process; designers prefer to wait until the end of the project to implement familiar technical solutions that could be influenced by adjacent modifications. Acoustics provide a good example: the acoustic performance of a vehicle results from complex interactions between various phenomena that are difficult to model. Any modifications to the design of the car are likely to affect the acoustics; consequently, it is necessary to wait until the design has been finalized before implementing any solutions that could, otherwise, very easily become obsolete. However, designers often use certain tricks of the trade in order to solve problems at the last moment
Design Problem Typology Treatment-Solution Delay Short loop Long loop Short
Box 1
2.3. Methodology Box 2
Project Schedule
Figure 1. Modification typology.
40
According to experts and researchers, recent front-loading strategies clearly contribute to speed up the detection of design problems during the development project. They are often mentioned as highly effective for design problems of types 1–3 (Boxes–3), when the nature of the problem and the potential solutions are known ex ante. But what is the effectiveness of these front-loading strategies when dealing with more innovative situations (Box 4)? Although all these front-loading strategies had been implemented, the Laguna II project encountered the major challenging problems of Box 4. Despite early signals, designers were neither able to diagnose the causes of the problems nor to appreciate how critical they were, or to suggest appropriate solutions. Therefore, it is legitimate to ask what the combined effects of the various approaches of front-loading are. What unexpected consequences are they likely to have, and do they meet increasing demands for innovation? In the remaining part of this article, we will examine the development of the Laguna II project and discuss the effects of such front-loading strategies in an innovative design situation.
Box 3
Latency Period Long
by, for example, adding cast-iron pieces, extra sound dampeners, etc.). In Box 3, design problems are taken into account rapidly, but their resolution takes a long time. Traditionally, tools tuning is representative of this case: it is often an empirical process of trials and errors that can last quite a long time. Lastly, Box 4 represents what probably constitutes the greatest threat to any project: a situation in which the diagnosis and resolution of a problem proves elusive, with the result that there is a pronounced risk of missing deadlines. The issue becomes yet thornier when the problem prevents the project from moving forward. Delays in diagnosing and solving problems are symptomatic of a degree of complexity not previously encountered: engineering expertise is pushed to its limits, either due to the use of innovative techniques or because of the high level of requirements.
R&D Management 37, 1, 2007
Box 4
Project Schedule
2.3.1. A case study We have chosen to use a case-study methodology (Yin, 1992). This methodology is actually highly relevant when dealing with the kind of emerging problems not previously addressed in the literar 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
Innovation and project development ture. In this case, the research process is more exploratory and aims at fostering an understanding of the phenomena at issue by formulating new hypotheses rather than testing pre-existing ones. In this context, the use of multiple sources is a key pre-condition for collecting robust data, which is why we have used a variety of information sources. For 2 years (1999–2001), we conducted 80 semi-directive interviews with top managers, project managers, engineers, technicians and suppliers working in various areas (doors, body, underbody), and took part in over 20 project and design reviews. We also studied archival sources (previous project post-mortems, project reviews and technical documents) and internal technical reports in which design problems were examined and solutions elaborated and justified. Data collection was followed by an information-processing phase with a view to elaborating a viable theoretical standpoint. Regular meetings between managers and researchers were organized in order to validate our findings and identify further issues for analysis. 2.3.2. A specific focus on design problems As we shall see later, the problems encountered in the Laguna II project were unexpected in nature and were discovered only in the late phase of the development process. To understand the causes of these difficulties, it was necessary to take a close look at the development process. Following Van de Ven, we adopted a longitudinal approach by focusing on ‘events’ that occurred within it (Van de Ven et al., 1999). For these authors, ‘the innovation journey is a sequence of events in which new ideas are developed and implemented by people who engage in relationships with others and make the adjustments needed to achieve desired outcomes within an institutional and organizational context’. In this perspective, an ‘event’ is considered as having occurred ‘when a change was observed in any one of these five concepts – i.e. ideas, people, outcomes, transactions and contexts’ (Van de Ven et al., 1999, p. 7). As we mentioned earlier, reducing the number of design modifications is one of the primary objectives of project managers. Design problems are the most significant events that project managers have to face in the later stages of the development process (the industrialization and ramp-up phases). In order to provide a consistent interpretation of the development process and its r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
successes and failures, we have listed some of the design problems (the ‘events’), and provided a careful analysis of their potential causes – organizational, strategic and knowledge-oriented – and consequences. Furthermore, we have paid particular attention to the collective learning dynamics required in innovative situations. When we began our research (18 months before the vehicle was set to be launched), the number of design problems was too great to be analysed in detail (around 500 had been identified by the project information system). We decided, therefore, to focus on design problems in a specific area: the doors, the body and the underbody of the vehicle, areas that are traditionally vital in development projects, and in which, in the case of the Laguna II, process innovations had been introduced in the new platform. Consequently, we collected data from the project information system where design problems are recorded and traced back. We sat in on design reviews and project meetings where design problems were discussed and various solutions suggested. As the project was converging through tests and trial and error, we were gradually able to elaborate a coherent picture of ‘the Laguna II development journey’ with all its surprises and unexpected problems.
3. The Laguna II development journey: a representative case 3.1. An exemplary case As mentioned above, the development of the Laguna II project is representative of a front-loading strategy applied to the creation of an innovative car. We had the opportunity to study the development of this project in real time and are thus able to discuss some of the salient effects of the strategy. The Laguna II project is part of Renault’s strategic effort to equal the performances of its most efficient rivals: Toyota in terms of lead times and innovation, and the German car manufacturers in terms of safety. After having introduced project management principles, Renault became a pioneer in the field of design-enhancing strategies. The firm has become involved in concurrent engineering, both internally by setting up crossfunctional product and process design units, and externally by introducing co-development strategies and development platforms grouping together all the participants in a particular project. This general approach has been consistently pursued at Renault: in the engineering sector, R&D Management 37, 1, 2007
41
Franck Aggeri and Blanche Segrestin designers and engineers were hierarchically integrated according to the vehicle modules they were working on. At the same time, the criteria used for evaluating external partners were more performance based. Lastly, the company has – while placing a strong emphasis on developing its ability to innovate – continued to rationalize its design approach by introducing multi-project management principles. The platform strategy was part of Renault’s overall approach: it set its performance targets very high and used a combination of all the approaches mentioned above. The firm’s objective was to design three different models using the same, new platform2. The first was the Laguna II, a vehicle whose level of performance was to equal or exceed that of its most advanced rivals, and whose many innovations3 were intended to boost the firm’s reputation in that particular field. All this was to be achieved by making substantial use of outsourcing and by drastically reducing not only development costs (by 20% compared with Laguna I) but also lead times (30 months instead of 42 months). To meet these targets, the firm not only called upon expertise acquired in previous projects, but also used major technical and organizational innovations: Several process innovations (new under-body production technologies, new materials such as aluminium) were introduced to cut production costs and reduce the weight of vehicles, thereby improving their performance. To speed up the project, a large number of prototypes were removed from the traditional work schedule. Emphasis was placed both on teams working upstream and on the use of simulation tools to do as much as possible to develop innovative techniques before work on the project proper was commenced. Lastly, reporting and monitoring schemes were introduced at all organizational levels in order to guarantee the global convergence of the project. At the start of the project, it was clear that a number of challenges would arise, but it was believed that adequate tools had been put in place to cope with them.
3.2. The development journey: from confidence to crisis During the entire initial phase of our study and for approximately 9 months after tooling equip42
R&D Management 37, 1, 2007
ment had been developed, both the project team and the technical directors were happy with the way things were going. Everybody agreed that cooperation between the teams assigned to various functions had improved considerably, that the budget was under control, that the schedule was being respected and that, according to all the indicators, the project as a whole was progressing smoothly. Indeed, it was only when the final prototypes were produced a few months before the scheduled launch of the model that a number of unexpected malfunctions came to light. At that point, the level of quality of the vehicle fell considerably short of the targets set. The quality control department pointed out that, in a number of specific areas, particularly in the doors, there were serious geometrical and quality problems, which required substantial adjustments. The adjustment process is a delicate one, consisting as it does of resetting the tooling (e.g. stamping presses) in order to correct geometrical misalignments and quality problems. It is an empirical process whose results are difficult to predict as each and every modification can generate new problems. Renault could not get away from the decision to delay the launch of the car so that the problems could be solved and the tooling adjusted. This belated discovery of problems came as a surprise to the firm’s management. As the ‘setting in stone’ of work schedules and deadlines is an essential motivational technique for participants in any project, the decision to delay the official launch of the product was clearly a difficult one. The final phase of the project was extremely turbulent: a number of problems proved very difficult to solve despite pressure from management and the deployment of considerable resources. In fact, the last quality control procedures were carried out a few months late. However, it should be noted that all the initial targets, other than deadlines, were eventually met. Hence, given the highly ambitious targets set for the project, the word ‘crisis’ is perhaps slightly overemphatic.
3.3. Analysing the crisis: the door panels The most delicate situations that designers had to face revolved around a limited number of specific issues, including a number of very complex problems with the side doors and the boot door, which had not been anticipated before the production of the final series of prototypes. r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
Innovation and project development An analysis of the various stages of the project reveals that, from the start, the doors implied a certain number of risky choices. Doors are traditionally one of the most difficult areas of any design project. They are large components that are difficult to stamp. Moreover, they fulfil several functions: they help keep the vehicle watertight, contribute to the safety of drivers and passengers and their geometry is vital from an aesthetic point of view. The quality of the doors, therefore, must be beyond reproach. In addition, over the course of the project, several design decisions were taken that had the effect of increasing development risks: the innovative design of the side doors and the boot door meant that they were particularly difficult to produce; new metal types were chosen, new stamping technology was used and finally, a new partner, who had never worked with Renault before, was accorded total responsibility for the design and production of the stamping machinery. As a result, conditions at the beginning of the project were relatively difficult. As the project progressed, shortcomings in supplier monitoring procedures became apparent. Adopting the view that plant equipment was the responsibility of the suppliers, Renault’s door design specialists basically focused on meeting economic and scheduling requirements. A number of reserves were expressed concerning the technologies used by the manufacturer’s partners, but those reserves were not followed up in a substantial fashion. Furthermore, many of the validations set to be carried out using physical prototypes were postponed several times because of frequent modifications to various components. Using digital validation systems, experts were able to identify risks of the doors going out of shape, but their interpretations were systematically questioned on the grounds that they were not representative of real production conditions. In fact, the only really representative prototypes were not produced until much later in the project, after the definitive tooling had been developed. It was at that point that geometrical and quality problems with the doors came to light. Renault’s partner was forced to admit that it had not been able to finalize component adjustments while at the same time integrating all the required modifications, and had therefore failed to meet the car manufacturer’s requirements. Pressure built up considerably during the final stages of the project, but still no satisfactory solutions were found. In the end, project leaders r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
called on the services of an internal specialist team, and Renault sent a group of experts with considerable experience in metal stamping to help out the tooling supplier. They alone were able to devise the adjustments necessary to produce the required components. Finally, after many months of trial and error and several hundred expensive modifications, an effective solution was eventually found. The doors turned out to be the most critical aspect of the development project, but they did not constitute an isolated case. Other parts of the project also provided late surprises, which required considerable engineering resources and necessitated numerous modifications.
4. Discussion: development methods for innovative projects The Laguna II project highlights the difficulties involved in innovating while at the same time improving product development performance in terms of costs, quality and lead times. The problems with the doors that were eventually brought to light during the final prototype phase was the result of a number of different factors, rather than of any specific failure. Indeed, from the beginning of the project, a series of very risky decisions was taken without sufficient attention being paid to the interdependence of those decisions. A number of initial conditions combined to render design problems difficult to identify and solve. Yet, how did it occur that all these initial conditions were not appreciated as extremely risky by the project management? How did it occur that the frontloading strategy failed to isolate problems before the final prototypes? This leads us to a discussion of a number of potential effects of front-loading strategies. It is our contention that the different techniques that were implemented to improve project management (cross-functional teams, contractual commitments and new partnerships, digital simulation . . .) were effective in addressing the problems of Box 1. But they proved inappropriate to apprehend new design problems, which finally became the problems of Box 4 (according to our typology; see Section I). Not enough attention was paid to early, but tricky, signals. These signals could not be interpreted through the existing knowledge: they were asking for collective learning processes during the project, but these learning processes did not take place. Lack of anticipation can thus be attributed to shortR&D Management 37, 1, 2007
43
Franck Aggeri and Blanche Segrestin comings in the kind of knowledge – especially technical knowledge – needed to identify risks. The Laguna II project revealed critical deficiencies in the competence–knowledge dynamic. The higher the level of innovation sought, the more essential it is to improve functional expertise; consequently, emphasis must be placed on isolating potential manufacturing problems under test conditions.
4.1. Side-effects of cross-functional integration on functional expertise dynamics In this regard, it seems that the effects of various strategic choices on functional expertise were substantially underestimated. Indeed, as we have seen in the case of the doors, some types of knowhow, such as stamping, are very difficult to maintain and to regenerate. Expertise in such fields, which generally results from the accumulation of various experiences, is very hard to transfer by means of explicit models. This analysis calls to mind the theory according to which functional expertise does not constitute a ‘stock’ of knowledge but is, instead, something that has to be continually renewed and reinforced using all appropriate means. As Hatchuel and Weil (1995) have demonstrated, the dynamics of functional expertise are less the result of an individual learning process than of a collective one achieved through continual exchanges between experts discussing concrete problems. Managers need to bear this in mind when reorganizing their engineering departments. However, in the firm studied, experts from different fields were, as in several American car manufacturers (Sobek et al., 1998), grouped together (product–process integration) in order to work on certain technical areas and communicate more easily with each other. This integration process was based on the idea that poor performances are mainly due to a lack of communication and co-operation between the departments responsible for specific functions. Of course, the integration of various departments reinforces cross-functional co-operation by bringing experts from various fields together in one place (co-location), a process that evidently encourages collective learning. Cross-functional teams as such are not to be blamed. But it should be noted that any structural changes will inevitably have ambivalent effects on the dynamics of functional expertise. Cross-functional teams are 44
R&D Management 37, 1, 2007
for instance likely to limit learning possibilities within a specific functional community. As Sobek, Liker and Ward have demonstrated, the success of a company like Toyota is largely due to the substantial degree of responsibility accorded to its hierarchical managers, men and women who are also genuine experts. In terms of project organization, these experts continue to play a central role by allocating tasks to specific individuals engaged in specific projects, and by negotiating the initial bills of order for components used in the design process (Sobek et al., 1998).
4.2. Limits of the logic of commitment At the same time, the continually increasing use of external design partners has long-term effects on the dynamics of functional expertise. As the role of technical experts becomes more economic and managerial in nature, they find themselves with less and less opportunities to experiment, a situation that increases the risk of a decline in technical knowledge. This insidious process was, in our view, one of the factors that led to the door crisis in the Laguna II project. The technical experts were no longer able to evaluate properly innovation risks upstream, and similarly, were no longer able to master the innovation process in the later stages of the project. Collective learning is essential in an innovative technology context. When new technologies are introduced, validation protocols inevitably become incomplete. In the case of the Laguna II project, the simulations failed to reveal new problems for the simple reason that you can only simulate what you already know. Such procedures need to be gradually renewed through input from concrete results gleaned as projects progress. But even there, outsourcing, by creating a gap between the car manufacturer’s experts upstream and the supplier, can have a negative effect on learning processes. Not enough attention has been paid by managers – or, indeed, by certain academic authors concerned with product management – to the dynamics of functional expertise in a highly innovative context in which veritable breakthroughs sometimes occur. Indeed, some academics have continued to insist on commitments and incentives. Inspired by a ‘commando spirit’ and a permanent quest for ever-improving performance, managers too often believe that problems are better solved under pressure or through incentives: a strategic approach clearly doomed to r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
Innovation and project development failure when the knowledge needed to actually solve a problem does not exist. As a matter of fact, in the case of the doors in the Laguna II project, the intense pressure exerted on the firm’s experts and partners proved ineffective.
4.3. Trap of ‘ready-made’ innovations or robust architecture According to Cusumano and Nobeoka, multiproject management is largely based on the transfer of technologies from one project to another under the aegis of an integrated monitoring system. This point of view is based on a belief that knowledge acquired through concrete experience is difficult to codify, and can, in effect, only be transferred by moving people from one project to another (Cusumano and Nobeoka, 1998). The case we have studied demonstrates that the transfer of technology and knowledge is a problematic concept. For example, if new technology is tested in other projects or under different conditions, problems can emerge unexpectedly due to interactions with which no one was previously familiar. The introduction of innovations produces unexpected effects and destabilizes existing practices. Consequently, it influences the number and nature of problems to be solved (MacCormack, 2001). This is particularly clear in the case of process innovations (new materials, new production technology), which, although invisible to clients, are those most difficult to implement. Innovation introduces unexpected interactions among modules and may even destabilize the architecture of the overall system. As it is impossible to test the entire gamut of possible effects produced by each and every potential interaction, the notion of pre-validated, ‘off-the-shelf’ solutions remains something of a utopia. Instead of relying on pre-validated solutions, we argue, with B. Weil, that the knowledge acquired through experimentation is more likely to be memorized in the form of what the author terms ‘half-technologies’ (Weil, 1999) or semidesigned technologies, i.e. technologies whose parameters need to be determined and verified for each new project.
4.4. Ambiguities of validation tests in an innovative context One widespread belief is that early problem-solving has been facilitated by the introduction of digital tools (simulations, rapid prototyping, etc.) r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
that make it possible to increase the rate of design-validation loops. According to the most optimistic forecasts, new digital simulation and digital mock-up tools could eventually make physical prototypes a thing of the past. But reality has militated against such predictions, which presuppose that tests are truly representative and present no problems of interpretation. But, as several authors have pointed out, interpreting test results is often an ambiguous affair as test conditions and expertise are often contested and sometimes ignored. In other words, tests do not always produce unambiguous results or automatically lead to concrete decisions (see the example of the Challenger Launch decision (Vaughan, 1997)). On the contrary, they may, following a process of procrastination, confirm managers and engineers in their previous choices (Akerlof, 1991). In the case of the doors discussed above, virtual tools failed to anticipate a number of problems that had never been encountered before and that, due to this very fact, could not be integrated into any appropriate computer models. In other cases, designers contested the results of calculations and simulations, either on interpretative grounds or because tests were not representative of reality. Consequently, the risks revealed by the tests were ignored. All this leads us to re-evaluate the approaches mentioned above. In effect, such approaches, which are based on the view that knowledge is an available quantum, display a tendency to neglect new ways of replenishing existing stocks of expertise. Organizations only recognize the existence of shortcomings ex-post, when it has become obvious that experts are unable to solve specific problems. In our opinion, validation tests should be considered first and foremost as learning opportunities; they are critical tools for designers in terms of identifying problems and can act as invaluable research guides. To use the terminology of Van de Ven, both ‘learning by testing’ – the kind of rationality underlying the decision-making process – and ‘learning by discovery’ – the kind of rationality governing actions taken – must be used (Van de Ven et al., 1999). This idea has important ramifications. The production of expertise is closely linked to an analysis of project development and the difficulties encountered therein. From this point of view, a critical analysis of the validation processes used throughout the project would be invaluable in terms of detecting problems that had not been identified early enough in the project. In our view, R&D Management 37, 1, 2007
45
Franck Aggeri and Blanche Segrestin such an analysis could prove highly fertile in terms of exploiting experience to create knowledge. A detailed analysis of an inefficient validation process should aim at fostering lively debate, achieving an understanding of what went wrong and identifying collective problemsolving tools.
5. Conclusion The case of the Laguna II project illustrates what Hatchuel and Weil (1995) have described as ‘hidden design crises’. In effect, the nature of design activity is difficult to pin down. Gaps in technical knowledge and project planning are, in most instances, compensated for by excess resources (organizational slack) and managerial pressure. In the example studied, the shortcomings of cross-functional integration, prototype elimination, outsourcing and other recent organizational developments were revealed by process innovations that pushed expertise and organization to their limits. The efficiency of organizational choices depends clearly on the degree of innovation, but this level is difficult to evaluate in advance. This case study highlights the difficulties involved in anticipating the degree of innovation. When Henderson and Clark (1990) speak of radical innovation, they refer to an ex-post evaluation (the judgement of customers). But it may be that most critical innovations for projects development consist in innovations that are not visible in advance. This is particularly the case of architectural and process innovations as they may have a destabilizing effect on organizational structures and existing expertise. Cross-functional integration, contractual commitments and new validation systems clearly contribute to the front-loading strategy when design problems can be managed with existing knowledge. But in innovative context, knowledge is not available anymore and needs to be produced. Then, these techniques may hinder the needed learning processes and impede the frontloading strategy. In other words, whereas these techniques assume that design problems can be detected through existing knowledge and can be solved thanks to available expertise, some innovations may be invisible through existing knowledge and experts may be devoid of solutions. In this context, neither clear-sightedness nor managerial pressure may help. It rather depends on expertise and appropriate managerial techniques 46
R&D Management 37, 1, 2007
to detect emerging problems and to reassess dynamically the degree of innovation. Seen from this perspective, the recent managerial doctrines must be complemented by other means in innovative contexts. What is at stake is the ability to detect the potential lacks of competencies and to reassess the degree of risks dynamically. What is called for in innovative projects is a framework in which collective learning processes can be fostered. We have identified some means that may play a key role in identifying ‘hidden’ innovations: communities of experts are central for knowledge dynamics; rather than validation procedures, ‘learning tools’ are required to identify gaps in knowledge and skills in a stepwise process, and to pave the way to further investigations; ‘half-technologies’ or semidesigned technologies are preferable to ‘on-the shelf’ solutions; and finally, ex-post analysis of the validation processes may also be useful to identify blind areas of tests and simulation tools. Another important recommendation can been derived from this case: as any strategic or organizational decision has the potential to influence the collective learning dynamic, managers must pay all the more attention when taking organizational decisions in innovative contexts. Changing the location and the role of experts will have an impact on the nature and frequency of their interactions with colleagues and, in the final analysis, on the kind of expertise they will be able to develop. In the case studied, shortcomings in terms of anticipating problems can be accounted for by the fact that managers did not realize that stamping expertise had progressively disappeared as a result of organizational decisions, namely the use of outsourcing and product–process integration. In and of themselves, such management techniques are neither good nor bad. What is at issue here is the degree of coherence of these combined approaches in specific innovative contexts.
References Akerlof, G.A. (1991) Procrastination and obedience. The American Economic Review, 32, May, 1–19. Baldwin, C.Y. and Clark, K.B. (2000) Design Rules, Volume One: The Power of Modularity. Cambridge, MA: MIT Press. Clark, K.B. and Fujimoto, T. (1991) Product Development Performance; Strategy, Organization, and Management in the World Auto Industry. Boston, MA: Harvard Business School Press. r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
Innovation and project development Clark, K.B. and Wheelwright, S.C. (1992) Organizing and leading ‘‘heavyweight’’ development teams. California Management Review, 34, 3, 9–29. Cusumano, M. and Nobeoka, K. (1998) Thinking Beyond Lean, How Multiproject Management is Transforming Product Development at Toyota and Other Companies. New York: Free Press. Fujimoto, T. and Thomke, S. (2000) The effect of ‘‘Front-loading’’ problem solving on product development performance. The Journal of Product Innovation Management, 17, 128–142. Garel, G. and Midler, C. (1998) An analyis of codevelopment performance in automotive development processes: a case study testing a win-win hypothesis. In 5th EIASM International Product Development Conference, Omo, Italy. Garel, G. and Midler, C. (2001) Front-loading problem solving in codevelopment: managing the contractual, organizational and cognitive dimensions. International Journal of Automotive Technology and Management, 1, 236–251. Hatchuel, A. and Weil, B. (1995) Experts in Organization, a Knowledge-Based Perspective on Organizational Change. Berlin: Walter de Gruyter. Henderson, R.M. and Clark, K.B. (1990) Architectural innovation: the reconfiguration of existing product technologies and the failure of established firms. Administrative Science Quaterly, 35, 9–30. Lundin, R.A. and Midler, C. (eds.), (1998) Projects as Arenas for Renewal and Learning Processes. Dordrecht, MA: Kluwer Academic Publishers. MacCormack, A. (2001) How Internet Companies build Software. MIT Sloan Management Review, Winter, 75–84. March, J.G. (1991) Exploration and exploitation in organizational learning. Organization Science, 2, 1, 71–88. Midler, C. (1993) L’auto qui n’existait pas, management des projets et transformation de l’entreprise. Paris: InterEditions. Moisdon, J.-C. and Weil, B. (1996) Current problems relating to design, coordination and know-how. In International research workshop COST A3-A4, Lyon. Nakhla, M. and Soler, L.G. (1998) Project management and internal contracts. In Lundin, R.A. and
r 2007 The Authors Journal compilation r 2007 Blackwell Publishing Ltd
Midler, C. (eds.), Projects as Arenas for Renewal and Learning Processes. Dordrecht, MA: Kluwer Academic. Sobek, D., Liker, J.K. and Ward, A.C. (1998) Another look at how Toyota integrates product development. Harvard Business Review, 76, 4, 36–49. Thomke, S.H. (2003) Experimentation Matters: Unlocking the Potential Effects of New Technologies for Innovation. Bostan, MA: Harvard Business School Press. Van de Ven, A., Polley, D.E., Garud, R. and Venkataraman, S. (1999) The Innovation Journey. New York: Oxford University Press. Van de Ven, A.H. (1986) Central problems in the management of innovation. Management Science, 32, 590–607. Vaughan, D. (1997) The trickle-down effect: policy decisions, risky work, and the challenger tragedy. California Management Review, 39, 2, 80–102. Weil, B. (1999) Conception collective, coordination et savoirs, les rationalisations de la conception automobile. Paris: The`se de doctorat de l’Ecole Nationale des Mines de Paris. Womack, J., Jones, D.T. and Ross, D. (1990) The Machine that Changed the World. New-York: Rawson Associates. Yin, R.K. (1992) Case Study Research: Design and Methods. Newbury Park, CA: Sage.
Notes 1. According to Cusumano and Nobeoka (1998), this approach makes it possible to go beyond the limits of ‘single project management’, which may cause ‘fat design’, a waste of resources and a situation in which components are poorly standardized. 2. These are high-end models (the Laguna II, the Vel Satis and the new Espace) that will be manufactured in the same plant (Sandouville); in total, an estimated 500,000 units will be produced annually. 3. The most visible innovation is the ‘key-less car’ concept, in which keys are replaced by electronic cards.
R&D Management 37, 1, 2007
47
