The product–process–organisation relationship in complex development projects

Research Policy 29 Ž2000. 913–930 www.elsevier.nlrlocatereconbase

The product–process–organisation relationship in complex development projects P. Nightingale ) Complex Product System InnoÕation Centre, SPRU, Mantell Building, UniÕersity of Sussex, Falmer, Brighton BN1 9RF, UK

Abstract This paper provides a framework linking products to innovation processes in order to show how knowledge, technology and organisation are all interrelated. These interactions create specific innovation management problems for companies developing complex, systemic capital goods. Firms can reduce development schedules and costs by efficiently allocating resources to reduce uncertainty about the implications of different design options. The paper proposes that technologies are constructed by following a set of interrelated problem solving tasks that constrain the range of possible innovation processes. The dynamic interactions between these interrelated tasks and the organisation of specialised labour influences the success of problem solving Žas does problem-solving technology. and consequently the number and extent of redesign feedback loops in the innovation process. These redesign feedback loops have implications for the schedule, cost and quality of the project. The more general framework is illustrated by a case study of product development in the aeroengine sector. q 2000 Elsevier Science B.V. All rights reserved. Keywords: Aeroengines; Uncertainty management; Complex product systems; Project management

1. Purpose The purpose of this paper is to develop a framework that links products to their innovation processes, to show how the complexity of systemic capital goods produces specific innovation problems that are not typically found in other settings. By linking knowledge, technology and organisation, the paper aims to explain how both design uncertainty and the number of redesign feedback loops can be

)

Tel.: q44-1273-686-758; fax: q44-1273-686-865. E-mail address: [email protected] ŽP. Nightingale..

reduced Žbut not eliminated., producing a shorter more cost effective development process.

2. Introduction How can project-based, systems-integration firms improve their development processes? And what is it about complex capital goods that creates large differences in project performance? A growing body of research suggests that the highly engineered, bespoke capital goods ŽCoPS. produced by systems-integration firms, pose novel product development issues not found in mass production, consumer goods ŽWalker et al., 1988; Miller et al., 1995; Hobday,

0048-7333r00r$ - see front matter q 2000 Elsevier Science B.V. All rights reserved. PII: S 0 0 4 8 - 7 3 3 3 Ž 0 0 . 0 0 1 1 2 - 8

914

P. Nightingaler Research Policy 29 (2000) 913–930

1998; Hughes, 1983..1 CoPS are generally characterised by high levels of user involvement ŽHobday 1998., a multifirm, project-based innovation environment ŽGann and Salter, 1998; Lemley, 1992. and heavily regulated, bureaucratically administered markets ŽMorgan et al., 1997; Burton, 1993; Walker et al., 1988; Sapolski, 1972.. They have high levels of uncertainty ŽHobday, 1998; Morris, 1990. and a reversal of the traditional selection of products by markets, with customers, suppliers, regulators and government bodies negotiating contracts, product designs and production methods before development is complete ŽWalker et al., 1988; Peck and Scherer, 1962; Woodward, 1958.. Moreover, their embedded software creates innovation problems not found in traditional capital goods ŽLeveson, 1995; Parnas, 1985.. Complex capital goods are also characterised by a large variation in the success of development, with larger, more complex capital goods showing high levels of failure ŽMorris, 1990; Marshall and Meckling, 1962.. Merrow’s study of 52 civilian mega-projects found an average cost overrun of 88% with only half the projects performing as expected ŽMerrow, 1988.. For large-scale software projects Gibbs Ž1994, p. 72. notes that Afor every six new systems that are put into operation, two others are cancelled. The average software development project overshoots its schedule by half; larger projects generally do worse and some three quarters of all large scale systems are ‘operating failures’ that either do not function as intended or are not used at all.B The GAO has reviewed large US government IT projects and noted ADuring the last 6 years, agencies have obligated over US$145 billion building up and maintaining their information technology infrastructure. The benefits of this vast expenditure, however, have frequently been disappointing. GAO reports and congressional hearings have chronicled numerous system development efforts that suffered from multimillion dollar cost overruns, schedule slippages measured in years, and dismal mission-related results.B ŽG.A.O., 1997, p. 6.. The same pattern of

1 Examples of CoPS would include mobile telephone networks, banking communication systems, flight simulators, high-tech infrastructure projects and intelligent buildings.

high failure rates, huge cost overruns and schedule slippages is found in complex military projects. The National Audit Office’s study of 25 projects in the UK Ministry of Defence’s Major Projects Statement found that 90% had failed or would fail to make their in-service dates ŽN.A.O., 1996.. Similar problems emerge in the construction industry, with the Channel Tunnel and Denver airport being notorious for cost and schedule overruns. All is not doom and gloom. A number of systems-integration firms manage to profitably produce high quality, complex capital goods that satisfy customers, within budget and on time. While high levels of project failure suggest that there is something different about CoPS innovation, the consistently successful record of some firms indicates that any inherent problems can be overcome. The issue is therefore; what is different about the complex, bespoke capital goods? And how can systems integration firms overcome their inherent problems? Answering these questions requires understanding how products relate to design processes. This paper builds on the work of Vincenti Ž1990. and develops a framework that shows how the technology-specific knowledge that is used to suggest uncertain ways of solving problems generates a set of interdependent problem solving tasks. The ability of firms to produce to cost, schedule and with full functionality depends on their ability to efficiently allocate resources and to coordinate their specialised knowledge and technologies to solve design problems and prevent costly redesign feedback loops. Since the extent of this redesign work influences the productivity of a project, there is an economic emphasis on uncertainty management. The framework is illustrated with an empirical case study that explains how an aeroengine firm improved its performance. 2.1. Limitations of the methodology The framework developed in this paper is illustrated with a case study of the development of an aeroengine. Case studies, like all methodologies, have inherent weaknesses. As Russell pointed out, with his example of the chicken that thinks the farmer is concerned about his welfare Žuntil the farmer wrings its neck one morning., empirical evidence can be compatible with a range of explanations. As a consequence, case studies without links to explanations

P. Nightingaler Research Policy 29 (2000) 913–930

can produce results that are time-, sector-, nationand technology-specific. However, when linked to explanations case studies can be a useful means of understanding behaviour provided that the explanation rather than the specifics of the case carries the argument. The case study in this paper should be interpreted as illustrating a theoretical explanation of a simple point: the more complex a product is, the more chances there are of its development process going wrong and the larger the potential variation in project performance. The argument is based on the explanation outlined in the theory section which tentatively suggests that innovation processes are dependent on Ži. the physical characteristics of the product, and Žii. the institutional and organisational structure of the firm. The case study is concentrating on these two factors, and has not examined the importance of marketing, finance, the contracting process, company culture, government–industry interactions, or changes in the external institutional structure of the industry. Both the case study and the theory therefore present incomplete and tentative pictures of CoPS innovation. The next section will explore product development and the gaps that remain in the literature. Section 4 will develop a theoretical framework for understanding how products relate to a range of possible innovation processes and how innovation processes relate to organisational forms, technologies and knowledge bases within the firm. Section 5 introduces the case study and explains the nature of the product and the industry, before illustrating the relationship between product and innovation processes. Section 6 will show how the case study firm moved from a high cost process to a lower cost process, while improving product quality. The paper ends in Section 7 with a review and discussion of the issues raised. 3. Product development This section briefly introduces the product development literature and then identifies unresolved issues. Started in 1968 project ASAPPHOB was one of the first attempts to systematically identify what differentiates pairs of successful and unsuccessful innovations ŽS.P.R.U., 1972; Rothwell et al., 1974..

915

Although the original study was based on process innovations in the chemical industry and product innovations in the scientific instruments sector, three major findings came through clearly and have been supported by subsequent studies ŽCooper, 1983; Cooper and Kleinschmidt, 1990, 1993; Maidique and Zirger, 1985; Bacon et al., 1994.. These are the following. Ø The importance of Aunderstanding user needsB throughout the company to ensure the final product matches customer requirements. Subsequent research has shown the interactive nature of user–producer interactions, and how they extend beyond simply Aknowing what customers wantB ŽTeubal et al., 1976; Mansfield et al., 1977; Rothwell, 1976; Cooper, 1986; Grieve and Ball, 1992; Lundvall, 1988.. Von Hippel Ž1976. has shown the importance of users as sources of innovation, and the case studies of the SAPPHO project illustrated the importance of making adjustments to technologies after they had been sold ŽRothwell, 1977.. Bacon et al. Ž1994., using a similar methodology to SAPPHO, found that using development engineers rather than marketing staff to liaise with customers, and using prototypes to aid customer feedback, produced superior results. Ø The importance of internal, cross-functional knowledge coordination. Subsequent work highlighted the performance differences between firms that integrate functional disciplines and those that have a sequential innovation process ŽBowen et al., 1995; Leonard-Barton, 1995; Iansiti and Clark, 1994; Rothwell, 1992; Womack et al., 1991; Clark and Fujimoto, 1991; Takeuchi and Nonaka, 1986.. The importance of organisational structure for knowledge integration has been highlighted by Galbraith Ž1973., Wheelwright and Clark Ž1993. and Clark and Fujimoto Ž1991. building on the original insights of Burns and Stalker Ž1961., while Rothwell Ž1993, 1992. has shown how information technology can improve integration. Ø The importance of strong technical capabilities as a prerequisite for incorporating external sources of knowledge. This has been supported by subsequent work on knowledge integration ŽPrencipe, 1997, 2000; Clark et al., 1989; Tidd et al., 1994.. Subsequent research has found that the balance between success factors is sector-specific ŽPinto and Covin, 1989; Dvir et al., 1998; Pavitt, 1984.. Within

916

P. Nightingaler Research Policy 29 (2000) 913–930

the complex capital goods sectors the importance of good project management, good risk control, and good management of the different agents within the innovation web have been identified by a number of authors ŽDvir et al., 1998; Hobday, 1998; Miller et al., 1995; Morris, 1994.. Insightful work has also revealed the particular problems associated with large-scale software development ŽBrooks, 1995; Gibbs, 1994; Boehm, 1991; Parnas, 1985.. In an important study of 110 Israeli defence projects Dvir et al. Ž1998. found that the balance of success factors was far from universal, with software projects being very different from hardware projects, and risk management and budget control unimportant for smallscale projects but vital for large ones. This empirical research raises a number of issues. The situation of a number of extremely robust findings on the determinants of product development success, and clear evidence that the balance between the different determinants Žboth the major ones and various minor ones. is sector- and technologyspecific, seems in need of explanation. The question revolves around why different products should have different balances of success factors, or put another way, what links the physical nature of products to effectiveness in their innovation process? A fruitful analysis of this interface can be found in the link between Atechnological trajectoriesB and AroutinesB in evolutionary economics ŽNelson and Winter, 1982., the link between ApathsB and AprocessesB in the dynamic capabilities literature ŽTeece and Pisano, 1994., and the link between sectors and dynamic Aorganisational capabilitiesB in the work of Chandler Ž1990.. Chandler’s work is of particular importance as it highlights that Aproduction systemsB are AsystemsB and emphasises the efficient division and integration of specialised labour, the importance of AthroughputB in determining economic efficiency and the role of technology in the production of technology.2 Despite this research, the exact mechanisms that link the physical 2

While Chandler’s Afunctional organisation–mass productionB model cannot be applied to the project-based development of one-off capital goods, the idea that the productivity of development and production is determined by the sophistication of production systems and their efficient and effective utilisation is applied here.

nature of products to their innovation processes and how these interfaces are mediated by organisational and institutional factors are not well understood. Vincenti Ž1990. has done important work on this interface in his analysis of aeronautical engineering and the co-evolution of knowledge and artefacts, Žsee also Ferguson, 1992, Petroski, 1986; Constant, 1980.. This paper extends Vincenti’s framework to explore how organisational and communication issues effect problem solving and consequently the schedule and cost of complex development projects. 4. Theoretical framework The theoretical framework adopted here links the product to its innovation processes by exploring the relationship between technology, knowledge and organisation. This relationship is mediated by Atechnological traditionsB that enable engineers to understand how the problems they face relate to similar problems with known solutions ŽNightingale, 1998.. This tacit Asense of similarityB allows engineers to propose potential solutions and turn the initial general problem into a more specific subproblem. The process can be repeated creating a hierarchy of increasingly specific subproblems and a corresponding set of problem-solving tasks. The order in which these tasks can be attempted will be constrained when the solution to one problem defines the specifications of others. This constrained sequence of steps, in turn, forms the basis for the innovation process. Specialists are assigned to the sequence of steps and attempt to solve their design problems by proposing, testing and modifying uncertain solutions. Potential solutions can be tested Žin decreasing order of reliability. by experiments, mathematical models and simulations, and tacit knowledge and Agut feelings.B If the tests show that the proposed solutions work as expected the engineers’ underlying assumptions and beliefs are reinforced. If the proposed solution fails its tests engineers use the test data to modify their understanding and a new cycle of trial and error is started.3 This process forms a Adesign 3 The results improve engineers’ understanding of the pattern between Achanges in starting conditionsB and Achanges in end resultsB which is then used to AtuneB the design.

P. Nightingaler Research Policy 29 (2000) 913–930

cycleB where iterative attempts are made to produce designs that come closer to the desired function. When tests show that design choices in previous stages were flawed, the innovation process has to feed back to earlier stages adding to its cost and schedule. Consequently, the relationship between products and their innovation processes is not direct. Firstly, there are a number of different technological traditions that can be used, so firms can differ in how they produce a product. Secondly, technological traditions only produce a series of problem-solving tasks, and there can be many different ways to arrange them, each with a different cost structure. Thirdly, firms can differ in their ability to solve problems so that the effects of incorrect design decisions are not discovered until further work has been complete, creating cost and schedule differences. As a consequence, there are a range of different ways of producing a product each with different cost structures. Firms that can more efficiently allocate resources and minimise redesign feedback loops can increase their Chandlerian Acapacity utilisationB and reduce the unit cost of developing products. However, the economic importance of avoiding redesign depends on the nature of the product and process, and more specifically, on product complexity. 4.1. Linear and complex innoÕation processes For simple technologies the innovation process typically breaks down into a linear series of iterative steps, but in many complex capital goods the function that the final technology has to express can only be produced by breaking the product up into subsystems and subcomponents ŽWalker et al., 1988.. This generates a ApyramidB of problem solving tasks for systems, subsystems and components that mirrors the physical structure of the product. As Vincenti Ž1990, p. 9. notes,4 the design process Afor devices that constitute complex systemsB is

917

Amultilevel and hierarchical . . . B The levels run more or less as follows from the top on down. 1. Project definition — translation of some usually ill-defined military or commercial requirement into a concrete technical problem for level 2. 2. Overall design — layout of arrangements and properties . . . to meet the project definition. 3. Major component design — division of project . . . 4. Subdivision of areas of component design from level 3 according to engineering discipline required . . . 5. Further division of categories in level 4 into highly specific problems. When the specification of subcomponents is only dependent on design choices higher up the design hierarchy, any iterations in the innovation process only effect components and subsystems that are vertically related. Difficulties occur when the subcomponents are systemically related across subsystems and design specifications move up, down, and across the design hierarchy. As Nelson points out AA particular problem in R & D on multicomponent systems arises if the appropriate design of one component is sensitive to the other components. Such interdependencies mitigate against trying to redesign a number of components at once, unless there is strong knowledge that enables viable design for each of these to be well predicted ex ante or that there exists reliable tests of cheap models of the new system.B ŽNelson, 1982, p. 463.. This is typical of many complex capital goods. These systemic complex products have temporal and iterative design processes because components require modification if their specifications are firstly, impossible to match, or secondly, incorrect. Redesign can spread if other systemically related, AsensitiveB subsystems have to be modified.5 If the process of updating design specifications takes time, the

4

Vincenti is referring to normal design, where what Polanyi Ž1962, pp. 174–184. calls the operational principle Ži.e., how parts fulfil their function in combination with one another. and the technologies’ normal configurations are well understood. For radical design work, the exact way the problem will be broken down may not be known and considerable research may be required to find an appropriate design, greatly complicating the innovation process ŽVincenti, 1990, pp. 208–211..

5 A good design process would make still make mistakes, as no redesign indicates that the technology is over designed and is not pushing the performance envelope sufficiently ŽHill, 1996.. Senior designers build up tacit understanding and develop Agut feelingsB about how close to the edge the amount of redesign is getting.

918

P. Nightingaler Research Policy 29 (2000) 913–930

design changes are extensive, or the components are related to a large number of AsensitiveB components, the amount of redesign work can be very large. There is consequently a danger of Aredesign chain reactionsB that spread through the different systems with disastrous effects, as when software systems are found not to scale properly and required fundamental changes. More commonly these systemic interactions reveal themselves in iterative cycles of problem-solving that take time to settle down into stable design configurations and add to the cost and schedule of projects. As such, complex capital goods have specific innovation problems that are not typically found in other environments and manifest themselves in increased numbers of failures, wide variation in development performance and increased requirements to manage risk, schedules and budgets.6 Since the likelihood of these problems is dependent on effective interproject communication, it is therefore related to the organisational structure of the project.

4.2. The organisation of complex deÕelopment projects Since the cost, schedule and quality of complex development projects depends on ensuring that design specifications are up-to-date and realistic, the productivity of development is influenced by the division of specialised knowledge and the flow of information between specialised groups. This intercommunication means that producing complex systemic technologies is not Alike picking wheatB where the actors can be assumed to be independent ŽBrooks, 1995.. If everyone has to communicate with everyone else on the project, the amount of communication will increase as the square of the number of people ŽBrooks, 1995.. Consequently, once projects get over a certain size the amount of extra communication produced by adding additional staff can be

6

The nature of the bidding process and the potential problems of customer and users changing design requirements during the development process create additional uncertainties that are not covered in this paper.

more than their contribution to the overall project ŽBrooks, 1995.. These communication problems can be reduced by specialisation and a division of labour, making some organisational architectures more effective than others at producing systemic complex products ŽBrooks, 1995; Marquis and Straight, 1965.. In particular, project-based organisations ŽPBOs. tend to be more effective than functional organisations when developing complex technologies ŽHobday, 2000.. While it would be possible to produce a complex capital good within a functional organisation, and indeed produce mass production goods as single entities in project-based organisations, the economics would be prohibitive. This is because flexible project-based organisations allow Ža. resources to be efficiently allocated in the project; Žb. knowledge to be managed for specific technical, regulatory and client problems; Žc. risk and uncertainty to be managed to ensure product quality; and Žd. increased flexibility in response to customer needs ŽHobday, 2000.. 4.3. Conceptualising complex deÕelopment projects The framework outlined so far can be used to conceptualise a continuum of project complexity in which various projects can be positioned according to their uncertainty and the likelihood of redesign feedback loops. The six main uncertainty factors are as follows. 1. Technological traditions established: If a development project has well established technological traditions that can guide the process towards designs that are known to work well, then the project is less likely to have redesign feedback loops. Consequently, radical innovations are more likely to fail than normal incremental design. 2. Intrinsic uncertainty of the technology: Differences in the laws of nature that determine how technologies behave can create differences in how easily technologists can understand the effects of design modifications. For example, understanding how design changes effect load-bearing beams is easier than understanding the implications of changes to fluid flows, combustion processes or software structures. Where these relationships are hard to

P. Nightingaler Research Policy 29 (2000) 913–930

understand there can be significant increases in the time and cost of development.7 3. Complexity of product: Increasing the number of different subcomponents increases the complexity of the design problems and consequently the complexity of the division of labour Žwith all its extra resource allocation and communication problems.. Moreover, above a certain level of complexity Aemergent propertiesB develop that cannot be predicted from first principles, which adds to the uncertainty of the system. 4. Systemic relationships between subsystems: If subsystems are sensitive to design changes elsewhere in the project redesign feedback loops can emerge that will have effects on costs and time-scales. This problem is compounded if systemically related subsystems occupy AunstableB areas of design space and small changes in function require large changes in design. 5. Fixed or unfixed problem: For complex pervasive technologies like capital goods the problem that they are designed to solve can change over the lifetime of the project due to Aemergent properties,B changes in customer requirements, changes in regulations and the impact of the technology itself on its environment. These changes add to the cost and schedule of the project. 6. Organisational rigidities: project success is dependent on effective intercommunication, which can be reduced by inappropriate organisational structures, cultural factors and physical and organisational distance. Of particular importance is effective verti-

7

This corresponds to Aareas of behavioural stabilityB in design space. APart of the innovation process involves finding the intrinsic parameters of these areas of behaviour stability and ‘tuning them’ so that they match design criteriaB ŽNightingale, 1998, p. 697.. The difficulties involved in AtuningB designs will depend on the nature of the interacting laws of nature that determine the technology’s behaviour Žwhat Stewart and Cohen, 1997, pp. 49–50 call the topology of the attractors in phase space.. For example, in aeroengines the design problems defined by the physics of fluid flows and thermodynamics etc., in software the design problems defined by the scale sensitive relationships between data-sets, algorithms, function invocations etc., and in explosives the design problems defined by the chemistry of auto-catalysis and pressure waves, etc. Instances where small changes in the design can produce radical changes in performance Žlike software and pharmaceuticals. create extra uncertainty.

919

cal communication that keeps senior managers informed of delays and problems. These six factors can all interact with each other, and produce a continuum from simple to extremely complex development projects; where the further along the continuum one goes the more likely a project is to have substantial redesign feedback loops. These feedback loops create extra organisational complexity and additional problems for project management and resource allocation. Thus a simple product with established technological traditions, a Astable design space,B limited complexity, little systemic interactions between its components and a fixed problem is unlikely to go significantly over budget or schedule. An incremental improvement to an established aeroengine design is more likely to go wrong because the implications of design changes are difficult to analyse and the product has a complex array of systemically related components. In the extreme, a very large, complex software project attempting a major technical advance with a constantly changing problem definition, a range of diverse organisations Žwith differing objectives and poor intercommunication. involved in its development is likely to suffer from severe cost and schedule overruns. 4.4. Uncertainty management in complex capital goods While complex capital goods have innovation problems that are not found to the same extent with simple products, there are a number of ways in which firms can improve their performance. Since the productivity of product development is dependent on the flexible and efficient allocation of resources and people, and on the ability to reduce the number and extent of redesign feedback loops, there is an emphasis on coordinated uncertainty management. Table 1 lists a range of solutions to design problems that allow development teams to control projects and reduce the likelihood of failure. These features and the general framework will be illustrated with a description of successful innovation in the aeroengine sector. The next section describes how the systemic complexity of aeroengines relates to possible innovation processes with different numbers of design cycles, and therefore cost and schedule structures. The section is followed by a descrip-

P. Nightingaler Research Policy 29 (2000) 913–930

920 Table 1 Design problems and solutions Project control

Preventing designs failing their specifications

Preventing design on wrong specifications

Improved design choices

Project management Risk management Contingency planning Good project communication Good leadership Reuse of old designs Use established technology Analysis during design process Simulations Management of Awork in progressB files Update of related designs Organisational changes Informal communication channels Organisational changes Input from along value chain

tion of what the case study firm did to reduce the number of redesign feedback loops and improve its performance.

5. Aeroengine innovation The theoretical framework outlined above is illustrated by an empirical case study of the design of the Trent 800 aeroengine at Rolls Royce. As the basic design of the aeroengines are relatively stable across different engine sizes and over time, the organisational and process changes are not the result of changes in technological traditions, but of an economic drive to improve efficiency as part of an ongoing restructuring of the aerospace market.8 The deregulation of the US airline market in the 1980s, following the Airline Deregulation Act of 1978, opened competition and hit airline profits. Airlines cut back their commitment to the Alaunch customerB scheme where they helped pay for the development of new aircraft models. This financial uncertainty put pressure on the plane manufacturers, who decreased their time-to-market from 4.5 to 2.5 years, which in turn increased time pressure on the aeroengine manufacturers, as their development times

8

For technologies with uncertain technological traditions Ži.e., software. the problems outlined in the framework would be worse.

are approximately a year longer. Aeroengine makers therefore had to reduce their development times or undertake costly, high-risk development work before the aircraft manufacturers had signed contracts. In response, the time to market of the Trent series of engines has dropped from 5 years to 39 months ŽRobins, 1996. and it is these changes that form the basis of this case study. While the technological traditions remained very similar, the relationship between processes and organisation changed fundamentally. 5.1. The nature of the product Large aeroengines are typical CoPS ŽHobday, 1998.. They cost some US$1 billion to develop, have 10–12 years negative cash flow, require about 2000 sales over 10 years, with cash flow increasingly coming from financial packages, parts and after-sales throughout a possible 40–60-year product life.9 The sector is heavily concentrated in three firms, Rolls Royce in the UK, and Pratt and Witney and GE in the US. In common with a number of complex products requirements are decided ex ante through a nonmarket process involving manufacturers, intelligent customers and national and international regulators. These requirements exist within the social context of Aairworthiness accreditation,B the international process that ensures aircraft and their engines are safe. Pressures to reduce operational cost have produced a shift towards fewer Žtwo rather than four., larger, more fuel-efficient engines, which requires a different approach to safety. To obtain accreditation for long over-sea crossings a plane must be able to fly for 180 minutes to complete the journey and land safely, having lost one engine during the flight. Moreover, each aircraft

9

The Trent cost over £500 million, the Pratt and Whitney PW 4000 cost US$800 million and the GE, GE-90 US$1.5 billion. ŽSkapinker, 1995.. This has led to collaboration between engine makers, with GE and Pratt and Whitney teaming up to develop a new engine for the Boeing 747. Boeing forecast 15 000 jet airliners will be built between 1995 and 2015, to a value of US$1100 billion, of which 3900 will replace existing aircraft. Rolls Royce forecast 18 700 with a combined value of US$929 billion, yielding engine sales of 34 200 jets and 11 600 turbo-props worth US$220 billion and US$150 billion in parts ŽDonne, 1996..

P. Nightingaler Research Policy 29 (2000) 913–930

must be able to safely take off and land after one of the engines has ingested a flock of birds. These institutional requirements require technically sophisticated machine that must function reliably in conditions which change from sea level to 50 000 ft, at speeds from zero to Mach 1 for civilian engines Žapproaching Mach 2 for military ones., and from the extreme cold of the upper atmosphere, to temperatures inside the engine 2508C above the melting points of some of the parts. The total Trent programme involved 200 companies, 14 000 hours of testing and 7500 man-years of engineering effort ŽRobins, 1996.. The aeroengine firms fit into a multilevel Aaerospace hierarchy,B that moves down from the uncertain requirements of airline operators, through to the airframers Ži.e., Airbus, Boeing. who increase the specificity of the requirements for the engine. The airframers pass these requirements to the engine manufacturers who assess the technological require-

921

ments and break the engine design down into subsystems Žcompressor fan, etc... The subsystem design teams fragment the design further until the final component specifications are sent to suppliers, or are manufactured in-house. In this aerospace hierarchy Arequirements pass down and definitions pass upB with the design problems becoming more specific at each stage ŽMoore, 1994, p. 4.. 5.2. Technological traditions to component breakdown The overarching technological tradition within the aeroengine sector involves producing thrust by accelerating and expelling air or gas at high velocity to produce an equal and opposite propulsive force.10 This initial technological tradition therefore changes the problem from one of providing thrust, to one of accelerating air or gas Žsee technological tradition table a1..

Technological tradition table a1 Desired end result Provide thrust

™

Q: What causes similar end result? Accelerate airrgas at high velocity

The problem of Aaccelerating airrgas at high velocityB can be solved by using a jet or propeller

™

Extrapolate solution Accelerate airrgas etc.

Žsee technological tradition table a2..

Technological tradition table a2 Desired end result Accelerate airrgas at high velocity

™

Q: What causes similar end result? Propeller Ž- 350 mph. Jet Ž) 400 mph. ignite airrfuel mix

Each solution has its own performance characteristics. Propellers are efficient up to 400 mph, after which turbulence from the propeller tips affect performance. Jet engines’ propulsive efficiency depends on their speed and they are less efficient below 400 mph. The design criteria selects between the two options and in the case study the speeds required made only a jet engine viable. There are again

Extrapolate solution

™

Use jet Žignite airr fuel mix.

several ways of producing a jet Žsee technological tradition table a3.. 10 For the sake of simplicity the technological traditions illustrated below concentrate on the production of AthrustB even though the airlines, airframe makers, international accreditation agencies andror military define a very complex set of design criteria based on thrust, safety, fuel efficiency etc.

P. Nightingaler Research Policy 29 (2000) 913–930

922

Technological tradition table a3 Desired end result Ignite airrfuel mix

™

Q: What causes similar end result? Ram jet Žforward motion compresses air. Pulse jet Žvalve encloses air during ignition. Rocket Žuse internal source of oxygenrair. Turbo jet Žexhaust turbine compresses air.

The basic design of aeroengines is well established, its history has been documented by Constant Ž1980., and its principles by Mattingly et al. Ž1987..11 The mode of operation is dependent on the thermodynamics of combustion and is very similar to an internal combustion engine, with an air–fuel mix taken in, its pressure and temperature increased, followed by its ignition and then exhaust. Each of the four design solutions will have its own Aperformance envelopeB and fuel efficiency for commercial flights will exclude all but the turbo jet, which uses a turbine driven by the exhaust gases to drive the compression process.

Extrapolate solution

™

Use turbine to compress air intake

It is at this point that the major discontinuity occurs between the manufacturers. The American engines traditionally have a Atwin shaftB design, while Rolls Royce has a Atriple shaftB design where a separate low-pressure turbine drives the fan Žsee technological tradition table a4.. This allows the fan, compressors and turbine speeds to be individually optimised leading to better fuel economy and a shorter, substantially lighter engine. The downside is that it makes the engine more complex and its original introduction played a part in the financial difficulties of Rolls Royce in the late 1970s.

Technological tradition table a4 Desired end result Use exhaust turbine to compress intake air

™

Q: What causes similar end result? 2 Shaft design 3 Shaft design ŽLP turbine drives fan.

The firms’ technological traditions provides the Aoperational principleB and Anormal configurationB of the engine ŽVincenti, 1990.. In the case of jet engines this involves linking a fan, low pressure ŽLP. compressor, high pressure ŽHP. compressor, combustion chamber, fuel system, exhaust system, etc. As the Trent 800 was a larger version of the Trent 700 series of engines the design was based on the earlier engine. Calculations and empirical tests were per-

11

The first jet engine patent was issued to Rene Lorin in 1913. Whittle developed the first working model in the 1930s.

Extrapolate solution

™

3 Shaft design

formed to provided performance specifications and to ensure the design criteria could be met.12

12 At each stage, the specifications for the function of each component and subcomponent are checked to ensure they are feasible. For example, future generations of fighters will be able to fly at certain speeds. In order to fly faster, military engines must produce a calculable amount of thrust, and this amount of thrust defines a performance envelope for the engine. To achieve higher thrust requires higher engine temperatures, but above a certain temperature the internal cooling systems will not work and turbine blades made in the traditional way will melt. As a consequence, alternatives to metal would have to be found ŽHill, 1997..

P. Nightingaler Research Policy 29 (2000) 913–930

923

Technological tradition table a5 Desired end result 3 Shaft design

™

Q: What causes similar end result? Fan blades ŽX size and specs. High pressure compressor ŽY specs. Low pressure compressor ŽZ specs. Turbine systems Fuel system ŽX, Y, Z specs. Etc.

The design problem has now fragmented into a series of subproblems based around each of the engine’s subsystems Žsee technological tradition table a5.. Taking the fuel system, its function is to control the flow of fuel for combustion at all operating conditions. These will include different temperatures, altitudes, speeds, starting, accelerating etc. The fuel system also has to ensure that the engine gas temperature, compressor delivery pressure, and the rotation

™ ™ ™ ™™ ™

Extrapolate solution Fan blades ŽX size and specs. High pressure compressor ŽY specs. Low pressure compressor ŽZ specs. Turbine systems Fuel system ŽX, Y, Z specs. Etc.

speeds are safe, as well as perform auxiliary functions like oil cooling. Since the flow of fuel is sensitive to changes in throttle position, air temperature, air pressure, velocity, engine speed, temperature and compressor delivery pressure the design criteria for the fuel system are systematically related to design criteria for other parts of the engine Žsee technological tradition table a6..

Technological tradition table a6 Žfuel system. Desired end result Fuel system with ŽX, Y, Z specs.

™

Q: What causes similar end result? H.P. fuel pump Ža, b, c specs. L.P. fuel pump Ža, b, c specs. Fuel flow regulator Ža, b, c specs. Throttle system Ža, b, c specs. L.P. shaft governor Ža, b, c specs. H.P. shut off cock Ža, b, c specs. Temperature control activator Sensor and control system

The same process could be repeated for each subsystem until the bottom level of the hierarchy is reached where simple subcomponents Ži.e. nuts and bolts. perform the required function. For the Trent engines the functional breakdown is AsolvedB by some 40 000 subcomponents so that the hierarchy of systems and subsystems in the product mirrors the hierarchy of problems and subproblems. The design hierarchy is not like the roots of a tree bifurcating into subroots, as many of the components are sys-

Extrapolate solution

™

Sensor and control system

temically related to components on other AbranchesB producing horizontal, as well as vertical, links in the hierarchy. 5.3. Component breakdown to innoÕation process The systemic nature of the interactions between subcomponents in aeroengines complicates the process of design in two ways. Firstly, specifications are passed up and across the hierarchy rather than just

924

P. Nightingaler Research Policy 29 (2000) 913–930

down. Secondly, the full performance criteria of some subsystems cannot be predicted from the performance of their parts, as testing may, for example, show unpredicted vibrations. Design therefore proceeds by an iterative process of testing and redesign until the systems perform as required. If design changes have a pervasive effect on other subsystems there is a potential for redesign feedback loops to emerge, or even worse, for Aredesign chain reactionsB where small design changes in subsystem trigger large-scale system redesign. If for example, a fan blade failed its final bird impact testing, redesign costs have been estimated at £100 million, and in a worse case scenario would require starting the design process from scratch. These redesign loops can have a substantial impact on cost and cost project schedules. A study of engineering costs in the 1970s found that some 75% of all hardware costs were spent on this iterative process of Acut and tryB hardware fitting and testing, as it can take a number of cycles before the design settles down into a stable configuration ŽHill and Langdell, 1993, p. 8.. Redesign feedback loops occur for three main reasons: firstly, the part fails to match its design specifications, often because it is operating at its performance limits in terms of dynamic load, temperature, stress etc. Secondly, the part can perform as expected but have its design criteria change when other systemically related subsystems need redesign. This is an important source of error in a technology with 40 000 interrelated parts. Thirdly, problems can arise with project management, scheduling, risk management, contingency planning and factors outside the design process. For example, testing and certification procedures can change during the design process. In all three cases the extent and effect of design changes can be minimised if designers can Asee the bigger pictureB and improve their understanding of how the part they are designing will function in relation to other subsystems and along the value chain.13 This reduces design uncertainty and the difference between actual and intended performance, which in turn reduces redesign feedback loops.

6. The management of uncertainty During the 1990s there has been a formalised process to manage uncertainty and reduce costly redesign based on spending more money earlier in the development process to reduce design uncertainty and identify potential problems.14 6.1. Project control: project and risk management Project control involves reusing historical design experience to flexibly and efficiently allocate people and resources and reduce unnecessary redesign feedback loops. Control is also maintained by engaging in formal risk management processes to appraise likely problems and ensure contingency plans are in place for any uncertainties. This is achieved by dividing new product development into three phases: new product planning, where approximately 10 engineers work closely with the airframe manufacturer to identify when a new market exists that can be matched to a technological competence. The next phase is full concept definition, where approximately 100 engineers work closely with customers to turn a market requirement into a technological specification, to identify what new materials, or manufacturing techniques will be required, and identify and appraise risks. In the third phase, product realisation, engineers specify designs in detail, perform risk analysis and mitigation, and develop contingency plans for any identified risks. In all three stages there is close collaboration with the customer and national and international aviation authorities who regulate the design work. 6.2. PreÕenting designs failures: capability acquisition, technology demonstrator programmes and simulations The three phases of risk analysis are supported by a formalised process of Acapability acquisitionB that makes sure that technologies and competencies are at a stage where they can be used directly in the engine. A technology demonstrator programme ensures new 14

13

For example, the designers can consider how the part will be manufactured and maintained.

Uncertainty reduction does not just include the design loop but also includes the manufacturing and service aspects so that problems throughout the development, manufacturing and operation of the engine are avoided.

P. Nightingaler Research Policy 29 (2000) 913–930

technologies have been demonstrated as physical prototypes Ain the engine, not just in the labB so any uncertainties involved in the innovative development of new technologies are separated from the development of new products. As the new technologies are shared across the product range they are centrally financed and assessed on their production Aspill over.B Redesign work is also reduced by reusing established, well-understood technology from the range of engines Rolls Royce produces Žfrom 2000 to 100,000 lb thrust.. This robust design exploits economies of scope in machinery, sales, marketing and after-sales, and enables tried-and-tested methods to be reused. It also allows the exploitation of learning curves and design traditions that guide engineers away from uncertain technical options and towards previously successful options ŽRobins, 1996; Ruffles, 1993.. The reuse of established techniques necessitates a sharing of people, not just data, so that tacit knowledge can be passed on face to face. This has been formalised into a system of classifying different technologies according to their maturity ŽMoore, 1995.. Low-tech components that present few problems can be dealt with by anyone in the project team. High-tech components or new technologies are controlled by specialists who ensure that they fully understand their behaviour before they pass them on to members of the project teams. This classification ensures that the functional groups who will repeatedly use a new technology acquire it first. The biggest improvement in design has come from using computer simulations and CAD systems to analyse component’s behaviour during the design stage, so that modifications can be made before embarking on expensive physical testing ŽMiller, 1995; Moore, 1995.. Before the electronic product definition system was introduced design calculations were a lot cruder, with more reliance placed on physical testing, which increased design time and effort. Now sophisticated simulations, particularly large-scale computational fluid dynamics ŽCFD. and finite element analysis ŽFEA. modelling, are used to help understand the effects of changes in design parameters. Predictions of blade vibration in wide chord fan blades and low-pressure turbine blades, for example, are now accurate to within experimental error.

925

Simulations also act as a Avirtual microscopeB allowing the detailed exploration of behaviour that would be very difficult to analyse experimentally. Computational fluid dynamics, for example, can be used to explore the aerodynamic properties of turbine blades, visualise combustion processes within the engine, model air and fuel flows and understand how they produce different emissions and temperatures within the engine ŽHill and Langdell, 1993.. These simulations complement ongoing experimental tests as they require experimental data for Ainput parametersB and to test their accuracy.15 The design process increasingly reuses old design data to produce a simulated Afirst cutB design which is tested and modified. For example, the fan blades of the Trent 800 engines are taken from previous designs, modified and tested on a Cray supercomputer 100 times over 3 months to optimise their design before the first blade was cast ŽMiller, 1995.. So, instead of an uncertain lengthy process of separate design, fabrication and analysis, simulations guide engineers towards established designs and allow earlier simulated testing which speeds up iterations in the design cycle. This allows more ArealisticB specifications, improved optimisation of the design and a wider scope of factors to influence design choices, while reducing uncertainty and redesign feedback loops. As physical tests can cost £1 million ŽRobins, 1996., there is a financial incentive to perform cheap, high-quality simulation.16

15

Simulations cannot replace all physical experiments because of a legal obligation to pass physical tests before the engine can be certified. For example, the engine must be able to contain a detached fan blade following a bird strike. The engine must pass a series of tests where birds are shot into the engine at high speeds. While it would be prohibitively expensive to model the behaviour of a real bird, Wilbeck and Barber Ž1978. have shown that it can be replaced by a hydrodynamic model of a cylindrical bird Žmade of water, gelatine and 15% air.. Simulations then take the Aworse caseB result ŽSchutter, 1988. and ensure that the engine could deal with it. If the engine can withstand a worse case scenario, it will pass the certification test. Birds are shot at model blades to generate the data to model a lower limit on fan blades and casing performance. 16 Similarly, in the construction of the Airbus A330rA340 800 different wing structures were simulated over two years, at the cost of £0.5m. Had the analysis been done in a wind tunnel, 800 sets would have cost £65 million and taken 150 years ŽHayward, 2000..

926

P. Nightingaler Research Policy 29 (2000) 913–930

6.3. PreÕenting incorrect specifications: document management, parametric design updates and organisational changes

that some out-of-date drawing will be used, wasting design time, or possibly contaminating the design process. Consequently it was a substantial management task to ensure that designs were kept up to date and designers were notified of any design changes that effected their work. To solve this problem computer systems have been developed that provide the right tools and files to the engineers’ workspace in the correct order. The data on the work-in-progress files is stored Ain a hierarchical structure based on wthe engine’sx geometric structure,B so that the hierarchy of design files mirrors the break up of the engine. The software monitors design changes, highlights any components that overlap in 3D space and electronically updates any files that are effected by design modifications ŽMoore, 1995.. The overall effect of computer simulations, robust design and improved document management is a reduction in the amount of uncertainty surrounding design decisions and a reduction in costly redesign feedback loops. Before the introduction of the changes, the design process would go through a series of steps during which errors could show up and the design would be Asent back to the drawing boardB Žsee Fig. 1.. The new system allows simulated analysis to take place during the design stage. While simulations are far from perfect and are complements rather than alternatives to experimental tests, they can increase the number of design cycle iterations, improve the final design and radically reduce the number of Acut and tryB design experiments that fail. This reduction in uncertainty allows designers to incorporate information from a larger section of the value chain, potentially optimising the design over a wider range Žsee Fig. 2..

Design uncertainty is also reduced when engineers understand how components interact with related subsystems. This partly tacit understanding is typically AtransmittedB between designers using drawings, diagrams and pictures that abstract a representation of what makes the technology AfunctionB ŽFerguson, 1977, 1992.. The interactions between engineers’ tacit understanding of how technologies will function in reality, and the diagrams that are used to represent this functioning, allows designers to represent and share their tacit understanding of how their designs will work with other members of the design team. This ensures that design work can be done on the diagram Žthe representation. and will correspond to a shared understanding of changes in the technology, which ensures that components will interact and work together ŽHenderson, 1999; D’Adderio, 2000.. The 2.5-million microfilm diagrams and 300 tonnes of paper diagrams used before computerisation shows how complex the process of transmitting accurate understanding of technical behaviour can be. Using blue prints enables complex problems to be divided up and understanding of components’ functions to be shared. This avoids two types of uncertainty: firstly, uncertainty where the definition of the problem is incorrect and designers produce components that do not function as expected because they have not understood the design specifications. Secondly, uncertainty that involves different groups of engineers having different understandings of the same problem and thereby producing incompatible solutions. With so many diagrams, it is inevitable

Fig. 1.

P. Nightingaler Research Policy 29 (2000) 913–930

Fig. 2.

927

process further so that Athese new systems and tools are being introduced integrally with the process changes and not as separate systems initiativesB ŽMoore, 1994, p. 1.. Changes in knowledge, technology and organisation are therefore interrelated: the tacit knowledge and data required for product development depends on the specific features of technology and the division of labour within the firm. The division of labour depends on tasks generated by the technological traditions, which in turn depend on the technology and the knowledge within the firm.

6.4. Organisational changes

7. Conclusion

Changes in the innovation process also produced organisational changes. Previously, development had been organised around a matrix structure where projects were Achucked over the wallB into its next stage of development. This has been replaced by a process and projects based structure involving a project team, who carry the new product through its development interacting with different subsystem process teams. The process teams specialise to ensure that the necessary technical expertise is in place, while the continuation of personnel allows continuous learning and ensures that tacit skills, understanding and technical information are readily at hand.17 Overall the innovation process changes in three ways. Firstly, the organisation of new product development was simplified to take advantage of the reductions in redesign feedback loops. Secondly, the new processes were supported with an electronic data network that ensured that the relevant work-inprogress files and design information was provided to help the concurrent design of the engine. Thirdly, a process of personnel continuation and sharing was introduced to ensured that sufficient knowledge was in place at each stage of the design process to fully comprehend and solve design problems. These three intertwined changes helped to integrate the design

This paper provided a framework linking products to their possible innovation processes. The paper argued that technologies are constructed by following a hierarchy of Atechnological traditions.B These technological traditions generate interrelated problem solving tasks that form the basis for possible innovation processes. Since firms can differ in how they produce a product, how the tasks are organised, and how good they are at solving technical problems, these processes are constrained rather than determined by the product. Consequently, the framework argued that complex capital goods have specific innovation management problems that are not found to the same extent in simple products. This is because they have large numbers of systemically related subcomponents and an increased possibility that redesigning one subcomponent will produce design changes in sensitive subcomponents. This creates the potential for Aredesign feedback loopsB whereby small changes have disproportionate effects on the innovation process. Avoiding these costly redesign feedback loops depends on reducing uncertainty and is done by firstly, making sure that the design matches its specifications, and secondly, making sure that the design specifications are correct. Firms that can flexibly and efficiently allocate resources within the project, reduce uncertainty and redesign should be able to develop projects at lower unit cost. The framework was illustrated with a case study of changes in an aeroengine innovation process. The case study showed how the introduction of computer simulations, the reuse of well understood technolo-

17 In 1995 the personnel split between processes and projects was 60:40 with the aim of eventually reaching 40:60. Rolls Royce has had problems ensuring that engineers do not develop Atechnological dialectsB that no one else can understand, and have made communication a priority.

928

P. Nightingaler Research Policy 29 (2000) 913–930

gies, organisational restructuring and other management changes reduced technological uncertainty and the number of redesign feedback loops, shrinking the time and cost of design. The methods highlighted in the case study reduce the organisational uncertainty associated with a given level of product complexity. Similarly, they can also be used to keep the level of organisational uncertainty constant and either increase the complexity Žand hopefully performance. of products, or increase the number of factors that influence the design choices Ži.e., factors further down the value chain.. Since these options can improve product quality, flexibility and performance there are economic incentives to adopt them, indicating that the features highlighted in this paper are unlikely to go away. The framework is presently over crude and further work is needed to better integrate its organisational, technical and temporal aspects. It does however provide an initial way of conceptualising how the innovation problems associated with systems integration might be overcome.

Acknowledgements The author thanks Dr. C. Moore, S. Miller, anonymous referees, Ammon Salter and Mike Hobday for their help and comments. The usual disclaimers apply. The work was funded by the ESRC as part of the Complex Product System Innovation Centre, jointly held between the Universities of Sussex and Brighton, Falmer, UK.

References Bacon, G., Beckman, S., Mowery, D., Wilson, E., 1994. Managing product definition in high-technology industries: a pilot study. California Management Review 2, 32–56. Boehm, B., 1991. Software risk management principles and practices. IEEE Software 1, 32–41. Bowen, H.K., Clark, C., Holloway, C., Wheelwright, S. ŽEds.., The Perpetual Enterprise Machine: High Performance Product Development in the 1990s. Oxford Univ. Press, New York. Brooks, F., 1995. The Mythical Man Month 25th Anniversary Edition. Addison-Wesley, London.

Burns, T., Stalker, G.M., 1961. The Management of Innovation. Tavistock, London. Burton, J.G., 1993. The Pentagon Wars. Naval Institute Press, Annapolis, MD. Clark, K.B., Fujimoto, T., 1991. Product Development Performance: Strategy, Organisation, and Management in the World Auto Industry. Harvard Business School Press, Boston, MA. Clark, K.B., Hayes, R., Wheelwright, S.C., 1989. Dynamic Manufacturing. Free Press, New York. Chandler, A.D. Jr., 1990. Scale and Scope: the Dynamics of Industrial Capitalism. Belknap Press, Cambridge, MA. Constant, E., 1980. The Origins of the Turbojet Revolution. Johns Hopkins Univ. Press, Baltimore, MD. Cooper, R.G., 1983. A process model for industrial new product development. IEEE Transactions on Engineering Management EM-30. Cooper, R.G., 1986. Winning at New Products. Addison Wesley, Reading, MA. Cooper, R.G., Kleinschmidt, E.J., 1990. New Products: the Key Factors in Success. American Marketing Association, Chicago. Cooper, R.G., Kleinschmidt, E.J., 1993. Major new products: what distinguishes the winners in the chemical industry. Journal of Product Innovation Management 10, 90–111. Donne, M., 1996. Demand takes off. Financial Times, August 30, Part II: 2. D’Adderio, L., 2000. Managing Information Systems in Product Development. Book Series on Industrial Informatics and Integrated Manufacturing Business Systems ŽIIIMBS.. RSPrWiley. Dvir, D., Lipovetsky, S., Shenar, A., Tisher, A., 1998. In search of project classification: a non-universal approach to project success factors. Research Policy 27 Ž9., 915–935. Ferguson, E.S., 1977. The minds eye: non-verbal thought in technology. Science 197, 827–836. Ferguson, E.S., 1992. Engineering and the Minds Eye. MIT Press, Cambridge. MA. Galbraith, J.R., 1973. Designing Complex Organisations. Addison-Wesley, Reading, MA. G.A.O., 1997. High Risk Series — 1997, General Accounting Office US HR 97-9, Washington, DC. Gann, D., Salter, A., 1998. Learning and innovation management in project-based, service-enhanced firms. International Journal of Innovation Management 2 Ž4., 431–543. Gibbs, W.W., 1994. Software’s chronic crisis. Scientific American 9, 72–81. Grieve, A., Ball, D.F., 1992. The role of process plant contractors in transferring technology. R&D Management 22 Ž2., 183–192. Hayward, A., 2000. The Future of Computing, Lecture at the University of Sussex, Brighton 21st Jan. Henderson, K., 1999. On Line and on Paper. MIT Press, Cambridge, MA. Hobday, M., 1998. Product complexity, innovation and industrial organisation. Research Policy 26, 689–710. Hobday, M., 2000. The project based organisation: an ideal form for innovation in CoPS? Research Policy, this issue. Hill, J., 1996. Personal communication. Hill, J., Langdell, P., 1993. Achieving fast and more economic

P. Nightingaler Research Policy 29 (2000) 913–930 engine design and development. Rolls Royce Magazine 3, 8–13. Hughes, T., 1983. Networks of Power: Electrification in Western Society. Johns Hopkins Univ. Press, Baltimore, MD, pp. 1880–1930. Iansiti, M., Clark, K., 1994. Integration and dynamic capability: evidence from product development in automobiles and mainframe computers. Industrial and Corporate Change 3 Ž3., 557–605. Lemley, J.K., 1992. The channel tunnel: creating a modern wonder-of-the-world. PMNetwork 7, 14–22. Leonard-Barton, D., 1995. Wellsprings of Knowledge: Building and Sustaining the Sources of Innovation. Harvard Business School Press, Cambridge, MA. Leveson, N.G., 1995. Safeware: Systems Safety and Computers. Addison-Wesley, Reading, MA. Lundvall, B., 1988. Innovation as an Interactive Process: from User-Producer Interaction to the National System of Innovation. In: Dosi, G., Freeman, C., Silverberg, G., Soete, L. ŽEds.., Technical Change and Economic Theory. Francis Pinter, London. Maidique, M.A., Zirger, B.J., 1985. The New Product Learning Cycle. Research, 14. Mansfield, E. et al., 1977. The Production and Application of New Industrial Technology. Norton, New York. Marquis, D.G., Straight, D.M., Jr., 1965. Organisational factors in project performance. Paper presented to the Second Conference on Research Program Effectiveness, July 25, 1965. NASA NsG 235, Office of Naval Research, Washington, DC. Marshall, A.W., Meckling, W.H., 1962. Predictability of the costs, time and success of development. In: Nelson, R.R. ŽEd.., The Rate and Direction of Inventive Activity. Princeton University Press, Princeton, pp. 461–475. Mattingly, J.D., Heiser, W.H., Daley, D.H., 1987. Aircraft Engine Design. American Institute of Aeronautics and Astronautics, Washington. Merrow, E.W., 1988. Understanding the Outcomes of Mega-projects. RAND, Santa Monica. Miller, S., 1995. Personal communication. Miller, R., Hobday, M., Lewroux-Demer, T., Olleros, X., 1995. Innovation in complex systems industries the case of flight simulation. Industrial and Corporate Change 4 Ž2., 363–400. Moore, C. 1994. Electronic product definition, the Rolls Royce Vision. Internal Document Rolls Royce. Moore, C., 1995. Personal communication. Morgan, F., Brady, T., Davies, A., 1997. The Turnkey Project Start-up Guide, Ericsson document ENrLZTG 501 104R1. Morris, P.W.G., 1990. The strategic management of projects. Technology in Society 12, 197–215. Morris, P.W.G., 1994. The Management of Projects. Thomas Telford, London. N.A.O., 1996. Major Projects Report 1996. National Audit Office, London. Nelson, R.R., 1982. The role of knowledge in R&D efficiency. Quarterly Journal of Economics 97, 453–470. Nelson, R.R., Winter, S.G., 1982. An Evolutionary Theory of

929

Economic Change. The Belknap Press of Harvard University Press, Cambridge, MA. Nightingale, P., 1998. A Cognitive Model of Innovation. Research Policy, 689–709. Parnas, D.L., 1985. Software aspects of strategic defence systems. Communications of the ACM 28 Ž12., 1326–1335. Pavitt, K., 1984. Sectoral patterns of technological change: towards a taxonomy and a theory. Research Policy 13, 343–374. Peck, J., Scherer, F.M., 1962. The Weapons Acquisitions Process. Harvard University Press, Cambridge, MA. Petroski, H., 1986. To Engineer is Human: The Role of Failure in Successful Design. Macmillan, London. Pinto, J.K., Covin, J.G., 1989. Critical factors in project implementation: a comparison of construction and R&D projects. Technovation 9, 49–62. Polanyi, M., 1962. Personal Knowledge. Chicago University Press, Chicago. Prencipe, A., 1997. Technological competencies and products evolutionary dynamics a case study from the aeroengine industry. Research Policy 25, 1261–1276. Prencipe, A., 2000. Divide and rule: firm boundaries in the aircraft engine industry. Unpublished PhD thesis, SPRU, University of Sussex. Robins Sir. R., 1996. The TRENT programme, a further step in engineering evolution. The 1996 Christopher Hilton Lecture, at the Royal Institute of Engineers, 1 October 1996. Rothwell, R., 1976. Innovation in textile machinery: some significant factors in success and failure. SPRU Occasional Paper no. 2, Brighton University of Sussex. Rothwell, R., 1977. The Characteristics of Successful Innovators and Technically Progressive Firms. R&D Management 7, 191–206. Rothwell, R., 1992. Successful Industrial Innovation Crucial Factors for the 1990s, SPRU 25th Anniversary, Brighton, University of Sussex. R&D Management 22 Ž2., 221–239, reprint. Rothwell, R., 1993. Towards the fifth generation innovation process. SPRU Working Paper. Rothwell, R., Freeman, C., Horley, A., Jervis, V.I.P., Robertson, Z.B., Townsend, J., 1974. SAPPHO updated, project SAPPHO phase II. Research Policy 3, 258–291. Ruffles, P., 1993. RB211 and Trent: basing new technology on established experience. Rolls Royce Magazine 8, 22–27. Sapolski, H.M., 1972. The Polaris System Development: Bureaucratic and Programmatic Success in Government. Harvard University Press, Cambridge, MA. Schutter, W., 1988. Bird behaviour during bird-strike. In: Pickering, C. ŽEd.., Science and Engineering on Supercomputers. ŽHorman.. Science Policy Research Unit, 1972. Success and failure in industrial innovation. Centre for the Study of Industrial Innovation. Skapinker, A., 1995. On and Wing and a Prayer, Financial Times, Friday November 24th, 1995, p. 21. Stewart, I., Cohen, J., 1997. Figments of Reality. Cambridge Univ. Press, Cambridge. Teece, D.J., Pisano, G., 1994. Dynamic capabilities of firms: an introduction. Industrial and Corporate Change 3, 537–556.

930

P. Nightingaler Research Policy 29 (2000) 913–930

Tidd, J., Bessant, J., Pavitt, K., 1994. Managing innovation: integrating technology, Market and Organisational Change. Wiley, London. Vincenti, W.G., 1990. What Engineers Know and How They Know It. Johns Hopkins Univ. Press, Baltimore, MD. Teubal, M., Amon, N., Trachtenberg, M., 1976. Performance in innovation in the Israeli electronic industry. Research Policy 5 Ž4., 354–379. Von Hippel, E., 1976. The dominant role of users in the scientific instrument innovation process. Research Policy 5, 212–239. Walker, W., Graham, M., Harbor, B., 1988. From components to integrated systems: technological diversity and integration be-

tween the military and civilian sectors. In: Gummett, P., Reppy, J. ŽEds.., The Relations Between Defence and Civilian Technologies. Kluwer Academic Publishing, London. Wheelwright, S., Clark, K.B., 1993. Revolutionising product development: quantum leaps in speed, Efficiency and Quality. Free Press, New York. Wilbeck, J.S., Barber, J.P., 1978. Bird impact loading. The Shock and Vibration Bulletin 48 Ž2., 115–122. Womack, J., Jones, D., Roos, D., 1991. The Machine That Changed the World. MIT Press, Cambridge, MA. Woodward, J., 1958. Management and Technology. Her Majesties Stationary Office, London.