2.1 Background

The word process is used widely in the world of engineering, industry, and business. It generally refers to a sequence of activities that produce a result. The dictionary defines it as ‘a series of actions or steps taken in order to achieve a particular end’. Similarly, ISO9001 talks of a ‘set of interrelated or interacting activities that use inputs to deliver an intended result’.

Examples of a process might include a manufacturing process to produce a component, an administrative process to produce an invoice, or an ‘HR’ process to recruit someone. The steps can be defined and the process can then be mapped and measured, which can, in turn, lead to improvement in the performance of that process. Above all, such processes are repetitive and happen with a relatively high frequency. Hence, the results of process improvement come through quickly and their success can be judged in days or months.

Technology and product development is also a process, albeit a complex one. It is not, as some have argued, a journey without a map. However, it is not highly repetitive – the timescale from end‐to‐end can be years or even decades – and each programme is uniquely individual. Improvement is therefore more difficult to achieve; indeed, some engineers in certain industries may only see two or three complete cycles in their working life.

2.2 The Basic Components of the Process

This is not to say, however, that considering the process of technology and product development is a futile exercise. It can be broken down into its elements, and an approach can be developed for each phase. In fact, later in the development process, there are more elements that are repetitive and specific, lending themselves to classic analysis and improvement. The earlier steps remain, however, more elusive and justify their description as the ‘fuzzy front end’.

For the purposes of this book, four phases of technology and product development have been identified:

1. Science
2. Technology research
3. Technology development
4. Product development

Science, in this context, is the process by which new knowledge is created for its own sake. For example, the science of semi‐conduction, or its forebears, was discovered in the 1820s with the observation that the electrical resistance of some materials decreases with temperature. It was some time before any real use was made of this phenomenon. Karl Ferdinand Braun developed the crystal diode rectifier some 50 years later, providing the basis of the first cheap domestic radios. It was another 80 years before semiconduction started to hit the headlines with the development of the transistor in 1947 and all that then followed in the computing industry.

Technology research is then the process by which science is developed towards some useful application and is the start point for this book. The development of transistors in the 1940s might be considered part of this phase, although much of the work could also fall into the category of science.

Technology development takes this useful application and progresses it to the point where confidence in it is much higher, through greater understanding of the detail, and where a commercial enterprise then feels able to commit to developing and selling a product to the marketplace. Transistors went through this process initially in the late 1940s and early 1950s in a number of laboratories, mainly in the United States.

The final phase – product development – and the most expensive, is where a useful product, such as a transistor radio, is made and sold in volume – first achieved, albeit in a very crude way by today's standards, in the early‐ to mid‐1950s.

The main phases of development are illustrated on Figure 2.1 whilst the details of the steps in maturing a new technology are described in much more detail in Chapter 3, which covers, in particular, the concept of ‘technology readiness’.

2.3 Expenditure on Research and Development

The processes of science, technology development, and product development make up a significant proportion of economic activity. In the developed nations, somewhere between 1% and 4% of those nations' economic output is devoted to R&D, as illustrated in Figure 2.2, which covers some 40 countries of the Organisation for Economic Co‐operation and Development (OECD).

These figures include expenditure by:

• Universities and other higher educational institutions
• Government
• Nonprofit private organisations
• Business (the largest contributor)

They also cover all forms of R&D, which are usually broken down by economists and funding organisations into three categories:

1. Basic research. For the advancement of knowledge.
2. Applied research. To acquire new knowledge, directed primarily towards a specific, practical aim or objective.
3. Experimental development. Directed towards specific new products and processes.

Globally, R&D spending was estimated in 2016 to total $1.95 trillion in purchasing power parity values for the more than 110 countries having significant R&D investments of over more than $100 million per year (Ref. 1).

This then plays into measures of innovation performance across nations, as ranked in Figure 2.3.

It can be seen, therefore, that technology development in its various forms is a significant activity in its own right. It is also argued that countries that spend a greater proportion of their GDP on these activities are also the most successful, economically, with 3% of GDP often being stated as a desirable target.

2.4 Economic Returns from R&D Work

There is a considerable body of academic work, probably unknown to most of the technology community, on the subject of linking R&D spending to economic success. Investment in R&D is like any other form of investment: resources are spent now in the expectation of future returns. However, unlike, say, the purchase of a machine tool, the returns can be some way off in the future, success is not guaranteed, and results may be difficult to attribute to one, specific piece of R&D. Nonetheless, work has been done to estimate the effect of R&D on sales, shareholder returns, market value, and margins (Ref. 3).

The results have a wide spread, as might be expected given the fact that any specific R&D project may be spectacularly successful or may be a complete failure. The ‘private’ returns to companies involved in manufactured products are estimated to be in the range 10–30% per annum. The term private here refers to the return experienced by the firm making the investment.

There is also the so‐called social return, which refers to the wider benefit which industry more generally experiences from R&D work. Findings in one company tend, over time, to spill over into other companies in the same sector or to other sectors. Supplier companies, for example, will serve several customers and may supply across sectors. Individual research engineers acquire tacit knowledge from their experience that will guide them in future work as they move from job to job. (Patents can protect specific designs, but the engineers will take with them the experience of what does or doesn't work or what approaches might be successful).

Social returns to R&D are estimated to be in the range of 40–100% per annum in manufacturing industries. The substantial gap between private and social returns is one of the arguments advanced for government support for R&D through grants or tax credits.

Overall, then, the economic returns from technology and product development are high, which helps explain why the percentage of GDP spent on research is growing in most countries. At the same time, the variability of returns emphasises the need to select and manage R&D projects carefully, a subject covered in more detail in Chapter 6.

2.5 Science as the Precursor of Technology

As noted in Chapter 1, science creates the foundation for new technology and hence new products. A look back in time, when life was arguably simpler, apparently shows a direct link between the great scientific discoveries of the seventeenth to nineteenth centuries and their application by the great engineering characters of a slightly later era, as illustrated in Figure 2.4.

Further investigation suggests that the relationship between science and engineering is less straightforward than this timeline might suggest. For example, there seems to have been limited connection, in the work undertaken, between the developers of the steam engine – Newcomen, Trevithick, Watt, and George Stephenson – and the scientists who preceded them, such as Hooke, Boyle, and Newton. The steam engine developers worked mainly by practical experimentation and development, rather than using theory and, if anything, their work prompted more investigation by the scientists, rather than vice versa.

In other cases, science clearly came before development. For example, maser (microwave amplification by stimulated emission of radiation) and laser (light amplification by stimulated emission of radiation) technology demonstrated in the 1950s by Charles Townes and others, and based ultimately on quantum theories developed by Max Planck in the early 1900s, was originally in the ‘solution looking for a problem’ category. Nowadays, of course, lasers can be found in a wide range of applications, from welding and metal‐cutting machinery to hi‐fi devices and then through to telecommunications using fibre‐optics.

2.6 Iteration as the Heart of the Process

As the preceding material suggests, an iterative loop is at the heart of the processes for developing technology and products. Sometimes described, somewhat pejoratively, as test – break – fix, it is really a learning cycle, as illustrated in Figure 2.5.

The cycle is used from the early stages of development – a sketch on the back of an envelope, a realisation that it's not quite right, followed by a redrawn sketch – to the later stages of sign‐off when small adjustments are made prior to final release. Leonardo da Vinci was an early and prolific exponent of the engineering sketch, as illustrated in Figure 2.6.

The process could be compared to W. Edwards Deming's Plan/Do/Check/Act cycle, much used in manufacturing improvement. He, in turn, credited this approach to Walter Shewhart, although its origins could be traced back to the seventeenth century as the ‘scientific method’: defining a hypothesis, experimentally testing it, then refining the hypothesis. Even the iterative model has its own multiple origins and cycle of improvement.

2.7 Impact of Low‐Cost Computing

New technology has also affected scientific and engineering development. Readily accessible and low‐cost computing methods have greatly enhanced the scope for more iterations of the learning cycle and hence potentially better results. Even something as simple as a spreadsheet, once set up, allows multiple ‘what if?’ studies to be undertaken. Going further, some complex models have the ability to be run repeatedly and automatically, homing in on the optimal solution. A feature of the Fourth Industrial Revolution will be more of this type of work.

2.8 A Nonlinear Process?

There is some debate as to whether technology and product development is a linear or nonlinear process. The real question here is whether or not the process can be characterised as a series of logical steps, which follow on from each other: do this and then do that, and so on. There is a degree of truth about both answers but it is certainly the case that you cannot draw a programme of events from the creation of a good idea to the launch of a successful product; innovation, unfortunately, is not that straightforward.

However, scientific discovery does tend to precede technology development. Design has to precede manufacture of prototypes. And detailed design does have to precede accurate cost estimation. There are many, many more examples of this logical progression, suggesting that there is at least a framework within which innovation, technology development, and product development must proceed.

But in the early stages of development, in particular, the exact destination and the route to get there will be uncertain, rather like exploring unmapped territory with unknown hills, valleys, rivers, and swamps. The exact application of a new technology may require some presentation of ‘what‐if's’ to customers and then further ideas based on their responses. Quite often, the eventual application may be quite different from the inventor's original idea. For example, the piston‐based steam engine developed by Thomas Newcomen and others in the early eighteenth century to pump water out of mines eventually led to the creation of rail networks. It is unlikely that this is what Newcomen originally had in mind.

These comments apply mainly to the early stages of development. Later‐stage engineering development follows a more disciplined and structured sequence, with a map to follow. However, the map may not be 100% accurate and the occasional detour, hopefully rather short, may be necessary.

2.9 Multiple, Parallel Activities

To add to the complexity of technology and product development, there will usually be multiple development cycles running in parallel and interacting with each other. This is always the case with very complex products such as aircraft, automobiles, or trains, where teams of 100+ engineers are very common. For example, just take the engine compartments of cars or trucks, which are usually very congested areas where components compete for the available space. It is normal practice to build digital or physical mock‐ups of these areas to flush out problems. As the designs for these areas progress, individual components interfere with each other and designs of individual components have to be iterated in parallel with each other to overcome these problems.

The same is true of systems, such as electrical power, air, or hydraulics. For example, as a design progresses, it might be found that the total electrical power requirements of the individual elements of a system exceed the output of the generator and a solution must be found either by reducing the power of elements or increasing the output of the generator. If the latter route is chosen, where does the mechanical power come from to create that extra electrical output?

The point to make is that multiple, parallel, or overlapping iterations have to be managed when a complicated product or technology is being developed.

This leads to the complexities of managing teams of engineers, with each person working on their own elements of a project. If there are two people in the team, there is then just one pairwise communication channel to manage. If there are three in the team, there are three pairwise channels; if there are 10 people, there are 45 channels; and if there are 100, there are 4950 channels in theory. In a large team, of course, everyone does not have to interact with absolutely everyone else but, as a first approximation, the number of communication channels goes up with the square of the number of team members (in a population of n, there are n(n − 1)/2 channels). This can lead to a situation where adding people to a team slows down the work because the added burden of communication outweighs the additional effort – see Chapter 5 for more about resourcing.

2.10 Right First Time versus Iteration

The iterative process described above may seem at odds with the philosophy of ‘right first time’, which rightly pervades manufacturing thinking. The underlying argument of right first time, in a manufacturing context, is that it is always more efficient to avoid defects by preventative means than to allow defects to occur, to inspect the product to identify them, and then to correct them.

Where there is a clear and repetitive process for manufacturing an item, it clearly makes sense to ensure that it works as perfectly as possible and that a conforming product is always produced.

So is there a different interpretation of right first time in the technology and product development process? If the underlying purpose of a right‐first‐time approach is to prevent defects, then what constitutes a defect in this process? Given that the purpose of process is learning and improvement, then a failure in the process is a failure to understand the learning which has occurred during an iteration loop and/or a failure to act upon it. This points us towards a philosophy of thoroughly understanding every learning opportunity, whether from digital modelling or physical testing, analysing the results carefully and always acting upon them rather than sweeping uncomfortable truths under the carpet.

This philosophy is the one of the keys to quality management in technology and product development.

2.11 Lean Thinking Approach

These points can be developed further by applying ‘lean thinking’ philosophies, as described, e.g. in James P. Womack and Daniel T. Jones' book (Ref. 4) of the same title. This concentrates on the identification and elimination of waste. Lean thinking is based around five key points:

1. The distinction between valuable and wasteful activities in the context of creating value for the ultimate customer of the product or service
2. The identification of value streams – activities that create benefits for these end customers
3. The flow of valuable activities as a continuous, ‘single‐piece’ process rather than a stop‐start batch driven process
4. The concept of pull, that is, only doing tasks when they are needed and not before
5. The principle of continuous improvement and hence the pursuit of perfection

These principles are most readily applied to the physical processes of manufacturing. It is no exaggeration to say that they have led to a fundamental and revolutionary shift in manufacturing efficiency.

As the book above points out, the same principles can be applied in other fields, specifically mentioning order processing and product development.

In the case of technology and product development processes, wasted activities do clearly occur in this field and are always, in principle, capable of being prevented. Value streams may be less obvious to see but usually include cross‐functional activities, involving departments outside the technology and engineering disciplines as well as suppliers. Because these value streams cut across organisational boundaries, they usually present the best opportunities for efficiency improvement but are the most difficult to tackle. Pull can be interpreted as doing the right things at the right time and not losing the synchronisation of cross‐functional activities, not piling up information before it is needed or providing information late. Finally, the concept of continuous improvement can be applied to any business process. More is said about these points in Chapter 12, improving product development performance.

2.12 Cost of Problem Resolution

The learning cycle described above does have a cost in the sense that the analysis of experimental test results and subsequent improvement activities do take time and hence cost money. However, in the early stages of a technology, this may be no more than a 10‐minute redraw of a back‐of‐the‐envelope sketch. At the other end of the spectrum, if a problem occurs when a volume product such as a car is out in the marketplace, the cost of rectification can be in £ millions.

A rough estimate, illustrated on Figure 2.7, suggests a logarithmic scale of the cost of remedying a defect – it's shown in pounds (6 on the scale is one million) but it could equally be dollars or euros.

2.13 Risk versus Time

When development of a new technology is started, the risk of issues emerging once the technology is in production is very high. This is simply a function of the early stage of its development and the fact that, at that stage, there is a lot that could potentially go wrong in the future. One of the primary objectives of the subsequent technology and product development process is to reduce that risk so that, when it does go into service, the risk of problems is as close to zero as possible. In well‐developed industries, this high standard can be achieved, although zero problems, i.e. perfection, will not.

This is shown graphically in Figure 2.8. The data are purely subjective and represent trajectories that might or might not be accurate.

This, then, raises the question of the extent to which risks can be identified and therefore anticipated – probably the most relevant and difficult question in the world of engineering.

The Johari window, Figure 2.9, or a variant of it, provides one framework for thinking, rather philosophically, about risk reduction in engineering. The original basic window is made up of a 2 × 2 grid, which lays out the relationship between personality traits known to the individual or known to others.

Developed by Joseph Luft and Harrington Ingham in 1955 (Ref. 5) as a means of mapping and understanding personality traits, a variant of it came to prominence through Donald Rumsfeld and his famous comments about ‘unknown unknowns’.

It is also a good framework for thinking about engineering risk. The four categories of risk that the matrix in Figure 2.10 identifies could be thought of as follows:

1. Obvious. Those on which both the developer of the technology and outside parties agree and where therefore consensus can be easily reached about what development might identify and overcome those risks specifically.
2. Experience. Those that the developer may have missed but that peers and grey‐haired engineers might identify from their experience.
3. Hidden. Those for which the signs are present but that the developer might be ignoring or dismissing, e.g. because test material is nonrepresentative.
4. Danger zone. Those that lie beyond the experience or expectation of all concerned.

A well‐known example of a ‘hidden’ problem might be that which brought down the Challenger space shuttle in 1986. In this instance, danger signals in the form of data from earlier failures or problems with O‐rings between sections of the solid rocket boosters were ignored. The disaster was investigated in great detail and it has become a case study in discussions of engineering safety and workplace ethics.

A less well‐known example of the danger zone is the collapse of a railway bridge over the River Dee, in northwest England, which occurred in May 1847 – see Ref. 6. The design concept for the bridge was relatively simple and had been used extensively over the previous 15 years or so. The principal structural elements were two cast‐iron girders forming the main spans of the bridge. Cast iron being weak in tension, the girders were asymmetric, with the bottom webs of the I‐beam configuration having more cross‐sectional area than the top webs. To provide still more load‐carrying capacity, preloaded bars were also provided to pre‐compress the bottom webs. These bars loaded the girders off‐centre and therefore also introduced a twisting load as well as the intended compressive load. The bridge failed catastrophically as a train went over it, and the cause was eventually traced to torsional buckling instability of the main girders, a phenomenon which was not understood at that stage in engineering history. In some respects, this is a classic example of an unknown unknown, but arguably more caution could have been exercised, as the bridge span was substantially longer than anything attempted previously.

These points suggest the adoption of a disciplined or structured approach to dealing with (1) to (3), but the need for more creative methods of discovering the unknown unknowns and the application of caution when entering uncharted territory.

2.14 Creativity versus Risk Management

The previous sections of this chapter illustrate one of the most fundamental dilemmas of the engineering process.

On the one hand, it is an essentially creative process, developing new ideas to solve problems and to improve people's well‐being. This is what attracts people into engineering and what provides the driving force to overcome problems. It is also the source of the innovation that drives business and economic growth in an industrial context. Jerome B. Wiesner, who was the thirteenth president of Massachusetts Institute of Technology, wrote, ‘Technical and scientific work is usually fun. In fact, creative technical work provides much the same satisfaction that is obtained from painting, writing and composing or performing music’ (Ref. 7).

On the other hand, those new engineering solutions have to be reliable, robust, and not create harm or danger. In this respect, the world is becoming increasingly critical – for example, we expect to be safe when we fly, and the figures demonstrate a civil aircraft safety level of around 0.03 fatalities every 10⁶ km travelled, a tenfold improvement in the last 70 years (Ref. 8).

Looking more widely, there is a strong expectation of safety and reliability in all the products or services that twenty‐first century consumers buy, as illustrated in some further numerical performance data in Figure 2.11.

The exact numbers are not so important as the fact that, in developing a new technology or product, the bar is set very high in terms of the reliability and safety levels that must be achieved (see, e.g. Refs. 9 and 10).

We are also increasingly aware of the environmental impact of new technology and, of course, new technology can solve as well as create environmental problems. Hence, the engineering process must constantly be aware of risks and problems that must be identified and overcome before a new technology or product is launched.

In this book, Chapter 6 is particularly focused on the new ideas, whilst Chapter 7 is focused on risk management.

2.15 Early Detection of Problems

The obvious conclusion from the previous discussion is that ways should be found to detect problems at the earliest possible stage, before they become expensive. As will be described in Chapter 3, there is plenty of evidence that higher levels of early expenditure are associated with lower levels of subsequent cost and time overruns. This logic may seem obvious, but it is not always followed, and it is difficult to compensate for underdevelopment by applying more resources later.

There are five ways, however, of addressing the issue:

1. Build early mathematical models, mock‐ups, and rig tests.
2. Plan the test programme at an early stage.
3. Work closely with materials, manufacturing, and supply experts.
4. Conduct expert reviews at an early stage.
5. Test ideas with customers, understanding and measuring their operating environment.

Thinking through what steps can be taken to detect problems at an early stage is probably the most cost‐effective investment that can be made in a technology or product development programme.

2.16 Management of Change

Given that learning and iteration are at the heart of development processes, change management is a key activity, sometimes thought of as a purely bureaucratic process but actually something far more fundamental.

Change in this context refers essentially to modifications to the engineering information defining a product or technology. In the early stages of a project, it could just involve redrawing the sketches, or remaking the calculations that lie behind a new technology at this stage of development. More likely, the term will be used to cover modifications to the myriad of drawing, modelling, and textual information that is required to define a complex engineering product.

In the former stage, few people are involved and changes or improvements can be handled informally and by word of mouth. In the latter stage, many people are typically involved and they may be widely distributed geographically. Hence, formal change control processes are the norm, preserving the discipline but often seen as an obstacle to progress. Those tempted to short‐cut might do well to study the 1981 Hyatt Regency walkway collapse in Kansas City – brought about by ill‐considered design changes.

This is the essential dilemma of managing change – a process that is core to the development of new technologies and products but one that can be expensive and difficult. Two approaches can help, both of which come from the Japanese automotive industry in the 1970s and 1980s:

1. Encourage changes but make them at the earliest possible stage.
2. Make change management a consensual and cross‐functional activity, rather than a bureaucratic process.

The first of these has already been covered. By identifying improvements at the earliest possible stage, the changes can be made with the least cost and frustration. This is also the stage when every effort should be made to minimise outright errors.

The second is where engineers, manufacturing specialists, and purchasing managers from all disciplines work towards the most effective solution. It does require an underpinning process, for example, to change documentation, to manage costs, to identify nonconforming material, and to agree the timing of implementation. If the organisation has been successful in flushing out improvements at an early stage, then these later‐stage changes should be relatively minor. However, they are still important for improving the product, especially its manufacturability, and any efforts to eliminate them are very undesirable, if not unrealistic (complete design freezes never actually work). It is also undesirable to impose a very demanding change process with multiple authority levels, which just slows down the inevitable. It is far better to encourage cross‐disciplinary working and to do this from the earliest possible stage.

2.17 Management of Learning

Changes, as described above, arise from learning about the technology or product under development. This will arise, typically, from analysis, manufacturing, or test work. Problems occur, and solutions may be found immediately or after further work. This learning is among the most valuable intellectual property that derives from development work. It is vital that it is not lost, and an effective problem or learning recording system should be an integral part of the development process. It does not need to be complicated and could simply include:

• A description of the problem encountered
• A record or analysis of the details of the problem
• An assessment of the root cause of the problem
• A note of the potential solution
• A record of the problem having been closed out in subsequent phases of work

As with the change process, learning processes can be handled informally or by word‐of‐mouth in the early stages of projects. Once the landscape broadens, a more formal process ensures that learning is not lost. For example, if early prototype manufacture is put out to subcontractors for parts manufacture, they will undoubtedly find problems, sometimes quite minor, and these opportunities for improvement should be captured. An important part of the latter stages of new product programmes is then working through all the records of all the problems that have been logged and ensuring that they have been dealt with.

2.18 Governance of the Process

The technology and product development processes described above do not lend themselves to detailed control and supervision, unlike, e.g. a manufacturing processes where items can be measured as they are made and rejected if nonconforming. In the engineering or technology development process, defects will not appear until much later, when the technology is actually being used in service, which could be a number of years after the defect is created. At the same time, the processes are critical to the long‐term health of organisations as the source of future customers, markets, and revenues.

Company management must therefore provide oversight to the process but cannot be expected to run it in detail. Strategic oversight can be provided through the following:

• Providing a climate within the company that encourages innovation
• Deciding, by screening of early‐stage technologies, which have potential future value and should be taken further
• Similarly deciding which technologies or products should be launched into a commercialisation phase, which could involve a major financial commitment
• Participating in formal reviews of products, via a stage‐gate process, for example, as they progress through the commercialisation phase
• Applying business analysis to the decisions noted above
• Undertaking business reviews of launched products in the marketplace to compare their performance with that planned

The points noted above are essentially concerned with an organisation's technology and product policy, which are clearly the domain of senior management and a critically important aspect of company strategy. For more discussion of this subject, see Ref. 11.

2.19 Formal Quality Management Systems

The points just noted relate to the policy management, by senior management, of technology and product development work. To complement this approach at the more detailed working level, formal quality management systems must also be applied. This is especially relevant when the product has safety‐critical elements to it, although it is just as important to good practice in all applications.

The engineering disciplines are responsible for generating and maintaining, for the organisation as a whole, data in the form of drawings, bills of material, specifications, test codes, and so on. These are important information assets upon which the whole enterprise depends in terms of accuracy, completeness, and timeliness. Without going into the structure and detail of a formal quality management system, the areas which need to be covered include:

• Responsibilities and accountabilities
• Identification and change control of drawings, documents, and specifications
• Management of bills of material
• Maintenance and calibration of test facilities and instrumentation
• Recording of results of analysis and test work
• Identification and traceability of test materials
• Recording and close‐out of risks and problems
• Maintenance of data integrity and security
• Audit of system performance

In an early‐stage company, these disciplines may seem unnecessary, but ignoring them tempts fate in the form of lost data, incorrect results, or misidentification of hardware. An ISO9001‐type system is vital from quite early stages of development. Large companies will already have such systems in place; smaller companies often delay the inevitable, to their detriment. It should be noted that these smaller companies will, sooner or later, find that they will be unable to do business without such certification, which is a mandatory requirement in the purchasing policies of many companies.

2.20 Concluding Points

The conclusion from this chapter is that there is an engineering, technology, and product development process. However, the process can be rather unstructured in its early stages, in contrast to the much more disciplined later stages. It is not a highly repetitive process: each project runs for a long time and is rarely repeated identically. However, it is characterised by a series of learning cycles. Multiple cycles often run parallel to each other, creating a highly interactive, as well as iterative, process.

As a fundamental principle, the more investment that can be made in the early cycles, and the more they can be cross‐disciplinary, the better the results of the later stages are likely to be. This, then, leads to the next chapter, which examines how the status and maturity of a new development can be assessed.

Perhaps the most perceptive comment about the engineering process comes from Appendix F of the Challenger disaster report (Ref. 12), an appendix written as a personal statement by Richard P. Feynman – a Nobel Prize winner in physics: ‘For a successful technology’, he concluded, ‘reality must take precedence over public relations, for nature cannot be fooled’. In other words, you can't fool or short‐cut the development of technology (although you can improve its efficiency).

References

These three references provide information about R&D from an economic perspective:

1. 2.1 2016 global R&D funding forecast R&D Magazine, Advantage Business Media. 2016.
2. 2.2 Global Innovation Index The Economist, 2015.
3. 2.3 Measuring corporate R&D returns ‐ Bronwyn H. Hall, University of California at Berkeley and Maastricht University, Jacques Mairesse, CREST‐ENSAE and UNU‐MERIT

Three references provide useful material about risks, problems, and waste in engineering systems:

1. 2.4 Petroski, H. (1994.). Design Paradigms – Case Histories of Error & Judgement in Engineering. Cambridge: Cambridge University Press.
2. 2.5 Luft, J. and Ingham, H. 1955. The Johari window, a graphic model of interpersonal awareness. Proceedings of the Western Training Laboratory in Group Development. Los Angeles, University of California, Los Angeles
3. 2.6 Womack, J.P. and Daniel, T.J. (1996). Lean Thinking. New York: Simon & Schuster Inc.

Thoughts from nineteenth‐century leaders in the field of engineering, including Wiesner, can be found in this compilation, still useful more than 50 years later.

1. 2.7 Love, A. and Chambers, J.S. (1966). Listen to Leaders in Engineering. Philadelphia: David McKay.

Information about aircraft, automobile, and process plant reliability and safety is available at

1. 2.8 ICAO Safety Report 2017 – United Nations International Civil Aviation Organization (ICAO) https://www.icao.int/safety/Documents/ICAO_SR_2017_18072017.pdf
2. 2.9 JD Power UK Vehicle Dependability Survey 2017 (VDS).
3. 2.10 Rick, J., Evans, C., and Barkworth, R. (2004). Evaluation of Reducing Risks, Protecting People. Institute of Employment Studies for the UK Health & Safety Executive, RR279.

More can be read about the overall governance of product development processes at

1. 2.11 Haines, S. (2013). Strategies to improve NPD governance. In: PDMA Handbook of New Product Development, 3e (ed. K.B. Kahn). Hoboken, NJ: Wiley.

The final comments come from the report into the Challenger disaster

1. 2.12 Rogers Commission Report, Volume 2, Appendix F – Personal Observations on Reliability of Shuttle, NASA – Richard P. Feynman, 1986.