14.1 The Rationale for This Book

This book is intended to be complementary to traditional academic engineering education, which teaches engineering theory and supporting practical skills. The book's central theme is how fresh ideas and new technologies can be taken forward and turned into successful products. In this context, it provides a framework and set of principles for approaching this topic. It does not, however, attempt to provide a formulaic approach, which is unlikely to work given that every situation has different needs and therefore requires a tailor‐made solution.

In the business community, ‘innovation’ is widely recognised as a crucial factor in maintaining the competitiveness of enterprises, as well as the spur to creating new businesses. From this point of view, the approach to technology and product development recommended in this book represents the practical means by which innovation can be brought to reality. It is based on the author's own direct experience, mainly in the field of complex engineering products but the principles can be applied more widely. The book should be of interest to engineers in the early stages of their careers, to researchers considering turning their ideas into commercial reality, to managers of non‐engineering functions, and to investors. It is deliberately written in nontechnical language.

A key objective of the book is to draw distinctions between ‘research’ work to identify potential new technologies, ‘technology development’ to understand fully those new technologies, and ‘product development’ to deploy new technology in saleable products. The term ‘engineering’ is used as an umbrella to describe all these activities.

Another key point is that technology is itself bringing about major changes in the art of engineering. Information technologies have radically changed the nature of engineering, particularly how analysis is conducted and how technical information is distributed in organisations. This process will continue as a Fourth Industrial Revolution takes hold. However, the fundamentals of engineering remain the same, such as the need to thoroughly prove products before they go into service – it's just that this can be done more quickly and more thoroughly with new technology.

Most of the individual topics in this book, of which there are many, are already the subject of detailed, single‐subject books. The purpose of this book is to tie these subjects together so that the process, as a whole, can be better understood.

14.2 The Engineering Process

The development of technology and products can be considered as a process, albeit one that is not used repetitively, time after time, as would be the case with a manufacturing process. Each project is somewhat different and the timescales in some industries, such as aerospace and defence, can be measured in decades. There are at least three distinct phases to this process, which, as indicated above, can be described as research (which is built on scientific discovery), technology development, and product development.

Taken collectively, work of this nature is a significant activity, typically occupying 1–4% of the GDP of developed nations and totalling close to $2 trillion worldwide. However, its real significance lies in the economic benefit derived from the products that emerge from the process. The economic returns from successful innovation are high. Returns within a company can be in the range 10–30% per annum, and the wider return to society, including spillovers, can be even higher. This is why governments are always keen to promote research and development work.

It is work, however, which is unpredictable, especially in the early stages. When new ideas are being formulated, it is difficult to draw up future timescales and programmes as a series of logical steps, except in the most general sense. This is less the case with the later, and more expensive, stages of product development where classic project management methods can be applied. On large projects at this stage, multiple activities run in parallel with each other, requiring active coordination but recognising that small decisions are constantly required at working level.

There is therefore no magic formula for generating ideas and turning them into successful products. However, broad rules can be followed, and some of the principles of lean thinking, as used in manufacturing, can be usefully applied.

The actual day‐to‐day process of engineering is essentially an iterative, learning activity. Ideas are formulated, tried, analysed, and tested. The work must also draw on previous experience, requiring an active input from seasoned engineers. Products, or the research and technology development coming before them, can be considered to have a high level of intrinsic risk in their early stages, gradually reducing as more development work is undertaken. The cost of remedying these risks is very low in the early stages, no more than amending a drawing, but is very high if the product is in the prototype stage or, even worse, in service.

The thoroughness of this process determines the eventual reliability of the end product. Public expectation of reliability is far higher than might be appreciated, whether the product is a car, aircraft, or domestic appliance. New firms find it difficult to match the reliability achieved by established companies, derived from their facilities, methods, and experience.

As with any high‐level process, rigorous underpinning processes are also needed. The overall framework of ISO9001 provides the starting point. Particular attention needs to be paid to the management of engineering change and to the process for recording and acting upon problems identified during all stages of development and beyond into service with end customers.

14.3 Technology Maturity

The concept of ‘technology maturity’ is a vital element of the understanding of engineering development. New technology, unfortunately, does not jump out of the box ready to go, moments after having an idea. In fact, the opposite is true: making technology work at the levels of cost and reliability expected by twenty‐first century customers is a long process. It is rather like human development, and any attempts at a short‐cut are likely to result in a 30‐year‐old with teenage habits – not a pleasant thought!

To develop this concept further, a mature technology is one that works reliably when in the customer's hands and can be manufactured consistently at the appropriate cost. It is likely to be used in a range of applications by a number of companies. An immature or underdeveloped technology is the opposite of these and will frustrate the end user.

The idea of a technology maturity scale came first from NASA in the 1970s when NASA was trying to understand why certain programmes overran and others did not. It eventually developed a nine‐level system, each referred to as technology readiness level, or TRL. This approach has been widely adopted across a range of industries and supports good decision‐making: for example, whether to incorporate a new technology on a new product programme, which technology developments to pursue, and whether to invest in a start‐up company. Other industries have developed their own TRL scales, each with slightly different characteristics, and the concept has been extended to include manufacturing readiness levels (MRLs).

This then leads to the concept of developing the technology and its manufacture alongside each other. Manufacturing work will always be somewhat behind the technology or product itself but, if the gap becomes too large, there is a danger of an unmanufacturable product emerging. When assessing the maturity of a technology, it is important to look at both the technology itself and the underpinning manufacturing work.

Methods are available for numerical assessment of readiness, and these methods are very useful in providing an objective understanding of the maturity of an idea, and hence what to do next. Quite frequently, certain aspects of new technologies are well developed but other areas are weak. The TRL level assigned to a developing idea is set by the weakest element. For example, the basic performance of an idea may have been thoroughly developed, but its safety performance may have been neglected. Synchronising the various elements of development is an important concept.

In principle, then, advancement of technology readiness is achieved by undertaking increasingly detailed analysis and testing with increasingly representative test material in an increasingly realistic environment. The process for doing this work can certainly be made more efficient, but all phases of maturity have to be worked through. The TRL and MRL scales give a common language for this process and can be used as a means of communication with nonexpert parties such as general managers or investors.

14.4 Aligning Technology with Business Needs

New engineering technology can be developed almost in isolation, but there is then much less chance that it will result in a successful economic outcome. It therefore makes sense, in the early stages of technology development, to think through how that development might be manufactured, sold, and supported, and how it might compete in the marketplace. Just a simple assessment, when a technology is at TRL 2 or TRL 3, will ensure that the development is heading in the right direction. Apart from anything else, this will make future funding more likely whether the development is in a university laboratory or in a company environment.

Manufacturing is a big business worldwide, some 15% of global turnover, so well‐presented ideas have plenty of opportunity for development. The idea must, however, be seen in the context of the competition and must have strongly differentiating features and/or must appeal to a very well‐defined target market unless it is able to compete on price alone. The latter is possible where the development is taking place in an already strongly cost‐competitive business but a new entrant will find it difficult to compete on this basis.

Whatever the competitive stance taken, the technology or product should be capable of articulation through a clear value proposition – as a short summary statement and as a somewhat longer map of benefits against customer needs. This then raises the question of identifying the customer. In some situations, there may be a single, clearly identified purchaser; in others, there may in effect be multiple customers, or the effective purchaser may be an engineer who specifies what will be bought. Identifying the true buyer is essential, and it may not always be obvious who that person is.

If a new technology or product is being developed within an established company, then the route to market will already be in place. Where it is being developed in a start‐up situation, there are several ways forward, ranging from developing own manufacture and sale to selling the idea to another business. Understanding the routes forward will, sooner or later, be essential.

Another decision concerns how the idea will be sold: will there be just one product design or will multiple options be needed to satisfy the customer base? Or will each application have to be engineered slightly differently? The ability to satisfy a range of customers is essential.

The product must also be capable of economic manufacture. This means, at a strategic level, employing methods of manufacture that a firm can access, either through its own resources or through its suppliers. At the operational level, it means optimising the details of the product so manufacturing and assembly are easy – difficult‐to‐manufacture parts invariably have quality problems. This process then extends to service and disposal.

It can be seen from these points that, far from being an isolated activity, technology development needs high levels of collaboration to be effective.

14.5 Planning the Work

Engineering covers a wide range of activities, from small‐scale technology development projects to very large product delivery programmes. All forms of projects benefit from at least a basic level of planning – it's a question of how much detail and where the emphasis should lie.

Every project should have six basic documents:

1. Project mandate
2. Project description
3. Milestone plan
4. Project budget
5. Risk analysis
6. Responsibility chart

For a small project, these in total need be no more than half‐a‐dozen pages; for a very large project, hundreds of pages will be necessary. The process of compiling these documents may be as valuable as the output itself.

Projects can be categorised according to their complexity and level of uncertainty. Simple but uncertain projects, such as early research work, need only the most basic planning, with approximate timescales and a small number of key milestones, but still taking periodic stock of progress, especially as new learning is revealed.

Large, complex projects clearly need very detailed ‘classic’ project planning and professional management. Before starting such projects, the technological risks need to be brought down to acceptable levels by preliminary technology development work. Otherwise there is a danger of such projects becoming both complex and highly uncertain: a recipe for expensive problems.

There are several ways of organising projects. In small organisations, such as start‐ups, the project might in effect be the company. In large organisations, projects can be organised around the company's ‘functions’ or, alternatively, dedicated project teams can be set up. Both approaches have their advantages and disadvantages.

Projects at their simplest level can be monitored through visual management methods, which can be conducted on a frequent, face‐to‐face basis. Large projects need more formal methods, including periodic stage‐gate reviews.

In summary, new technologies and products are delivered through projects: time‐bounded activities with specific objectives. As technology advances in maturity, these projects become more structured, more complex, and more commercially focused, with an expectation by investors that results will be achieved. The basic disciplines of project management are valid at all phases of development: the ‘fuzzy front end’ through to multimillion‐pound commercial projects.

14.6 Creating the Concept

Arguably, the most interesting part of engineering is having ideas and turning them into new product concepts. This phase of work brings together future market needs, new technological possibilities, and economic viability. As with other phases of work, early‐stage development is an iterative mix of creating ideas, matching them with gaps in the market and testing whether the solution is likely to work financially.

Some ideas will simply be incremental developments of those that exist already, such as small‐scale improvements on last year's product. Much less frequently, radically new ideas emerge and create markets that just don't exist currently.

Ideas can come from a variety of sources: company engineers or salespeople, long‐range technology forecasts such as technology roadmaps, other sectors of industry, research engineers in universities, start‐up companies, suppliers, or private individuals. Research has shown that three factors tend to determine the success of new products:

1. The superiority of the product in terms of the features it embodies
2. The extent to which customer needs have been investigated in detail
3. The amount of effort invested in early‐stage product development

Customer data gathering, in detail, and customer understanding are clearly major factors at this stage, and two models can improve the effectiveness of concept development. The Kano model is often used to guide the understanding of customer needs, and then the quality function deployment (QFD) model is a powerful way of linking customer needs to engineering design detail.

Early‐stage technical work forms the foundation of future development: it develops a concept that will appeal to customers. It must also identify critical issues and risks and do sufficient work to show they can be overcome subsequently. A parallel and realistic financial evaluation is a further, important element of concept development.

This is also the stage where intellectual property (IP) protection should be put in place. It could take the form of patents but could take other forms such as copyright and trademarks. Premature disclosure of ideas at this stage should be avoided, as this can prejudice IP protection.

Some level of public funding may be available for early‐stage work, especially in the research and concept development phases. There are drawbacks to using these sources but they can provide welcome injections of cash to new organisations.

Concept development suits a small, multifunctional team environment – the work is not easily subdivided and is fast changing. Formal documentation of the work is helpful in as a means of capturing what has been done and as a discipline to ensure that the concept has been fully thought through with no inconsistencies.

14.7 Identifying and Managing Risks

Whilst developing a new concept represents the most interesting part of technology and product development, the enthusiasm for the new must be tempered with a counter‐balancing consideration of the risks that something novel might introduce. Such risks can take many forms, from a simple failure to work quite as planned through to outright catastrophic failure leading to loss of life.

Within this context, the risk management approach identifies all possibilities of failure and evaluates them according to their likelihood and to the severity of their consequences. Action is then taken in proportion to these factors. It is through this approach that consumer products such as cars have such high levels of reliability, and rather hazardous activities, such as flying at 500 mph at 35 000 ft, are regarded as everyday occurrences.

The basic root causes of risks and failures are relatively straightforward, and include design‐related issues, defects introduced through manufacturing, mechanical failures, electronic component failures, and software design malfunctions. The aim of much engineering development is to minimise the likelihood of these occurring, noting that complete freedom from risk is unattainable.

There are several well‐established ways of evaluating risk, such as failure modes and effects analysis (FMEA) and fault tree analysis (FTA), which were first used in the 1950s and 1960s. Industries in the public eye, such as nuclear, aerospace, process, and oil and gas, are very strong in this area, having suffered some serious catastrophes such as Flixborough, Three Mile Island, Challenger space shuttle, and Piper Alpha. These industries have built on the basic methods and introduced quantitative approaches that estimate numerically the likelihood of failure and evaluate the consequences, such as injury or damage, also in numerical terms.

These methods are becoming wider in their application as more products and systems become dependent on software and control systems for their safety. Whether it is something as simple as an automatic door opening system in a supermarket or a control system for a nuclear power plant, ‘functional safety’, as it is called, is an increasingly important topic.

These thoughts must also be tempered by what is practicable and economical. The ALARP concept (as low as reasonably practicable) has been developed to identify which risks are just unacceptable, which can be discounted, and which should be brought down to acceptable levels. Of course, what is considered unacceptable is becoming stricter over time.

Risk identification and management is one of the primary mechanisms for embodying the lessons of the past. Learning from the failures of the past is central to the engineering process.

14.8 Validation

Engineering validation is concerned with the analysis, modelling, and testing activities, which are used to minimise engineering risks and ensure a reliable product. It covers validation of performance, legal compliance, product life, response to extreme conditions, and reliability. Whatever form of validation is used, problems are identified, causes understood, and solutions tested – essentially, a process of learning. All new developments need a thorough and well‐planned validation programme to achieve competitive reliability.

Analysis by engineering calculation, based on engineering theory, is the starting point and is readily applied in the early stages of a new technology programmes. Most theory is available as pre‐programmed software. More detailed mathematical models are then used to take analysis to a higher level of complexity and detail, examining complete products, systems, processes, and their performance. The success of both analysis and modelling is very dependent on the correlation that can be built up with real life. Modern software makes it very easy to create realistic‐looking models and hence the illusion of accuracy. Engineering companies build up this correlation over time, usually in the form of development codes and resulting in very accurate simulation methods. Start‐up organisations will have to develop this capability over time and must take care not to be overconfident as this process evolves.

Trialling by physical testing is the ultimate assessment of a new product and clearly the closest to real life. However, the realism of modelling methods has progressed to the point where physical testing is often used more as a means of confirmation than fundamental development. It should be noted that physical prototypes are often the first time that all a complex product's systems come together, and hence their unexpected interactions can be understood. Testing clearly needs access to facilities, instrumentation, and analysis methods. Performance testing is relatively straightforward but life testing needs accelerated methods, which also need to be correlated over time.

In some instances, e.g. where the product is very low volume or a one‐off, prototyping may be difficult or impossible. The sold product must then go through a commissioning period which must be carefully managed to achieve customer satisfaction.

Later in development programmes, numerical measurements of reliability can be made if a statistically significant number of products can be made by production methods and operated in realistic conditions – product reliability is set by the thoroughness of the development programme and is not inherent in the design.

14.9 Engineering Delivery

Delivery is concerned with the conversion of a fully developed and validated concept into a formally defined product that can be manufactured with confidence, sold, operated, and retired. The output is information, almost certainly in digital form, such as drawings, bills of material, specifications, and other documents. The engineering function acts as the originator and custodian in most organisations of this data and ‘owns’ the information, applying formal issue control to it in line with quality management requirements. The data, however, will have been created collaboratively within the organisation and represents an important corporate asset.

In contrast perhaps to the more creative aspects of technology and product development, this is a detailed and exact form of activity, which provides the basis for making known and traceable products.

This activity covers TRLs 7–9 and MRL 5 and upwards. It consumes the majority of the resource and cost of the development programme through detailed design, modelling, prototype manufacture, and test work. Given the amount of resources consumed and the number of activities undertaken, it requires careful planning of the key milestones using classic project management techniques.

There will still be some learning and iteration during this phase of work, but it will be containable if the product specification and technology have been properly researched in earlier phases. However, with inputs from design engineers, manufacturing engineers, suppliers, and other parties, close teamwork is needed, backed by responsive but formal change control. Detailed management responsibility should be delegated to team level, where most of the new information originates and where solutions to problems can be found. Co‐locating multifunctional teams on either a periodic or permanent basis can have a big effect on the speed of the work at this stage. Good systems in terms of progress tracking, learning points identified and closed, and accessible product databases have a similar effect.

Specialised resources can be troublesome bottlenecks, slowing down this phase of work. These could take the form of specialist engineers, managers for sign‐off, analytical resources, or test facilities. Conscious management of bottlenecks is recommended, and it should be appreciated that there is a trade‐off between utilisation and throughput time, with high utilisation causing surprisingly long queues of work.

Towards the end of this phase of work, a formal sign‐off process should be used to ensure that all requirements have been met, all learning points have been closed, all reviews completed, and legislative requirements met. The product may then be ‘released’ without conditions or it may be concluded that a conditional release can be given pending completion of certain tasks.

This is an important decision point at which an organisation commits to volume production and all that it entails.

14.10 Funding the Programme

All developments require money, irrespective of the organisation (start‐up or established company) or the stage of development. Persuading an investor or a hard‐headed corporate finance man to provide this money is part of the charm of engineering. Some form of business‐related plan is a prerequisite to any form of development, with the level of detail increasing with the level of planned expenditure. As a minimum, the plan must explain why customers will buy the product, how it will be made and sold, and what resources are required to make progress.

In established companies, funding will generally be provided from sales‐generated cash flow, although new money could also be raised. In a new company, personal money, or that of friends and family, is the start point. After that, angel investors might be persuaded to contribute followed possibly by crowd‐funding. Venture capital, banks and public offerings come later. The most difficult period for funding is between demonstration of a concept to the point where a new company is generating some level of sales revenue.

Public funding for technology development, and physical facilities, do exist to cover this period, but it is normally available only for the technology itself and rarely for production facilities, for example.

14.11 Running Teams and Working with Partners

The previous material has concentrated on the structure of engineering programmes from early‐stage ideas to series production. It could be inferred that the processes used are essentially mechanistic, and therefore easily put in place. In reality, they depend very heavily on human aspects of collaboration and cooperation. Hence, a basic understanding of human dynamics is an essential element of successfully managing such work. It is easy to underestimate the importance of the topic.

The basic building block for this type of work is the team, rather than the individual. Although there may be a central, core team, the wider team could be somewhat dispersed, especially when suppliers, customers, and partners are taken into account. Team building and team dynamics play an important role. This topic is well researched, and the characteristics of both successful and unsuccessful teams are understood in terms of their composition, development, and dynamics. Organisations will find that paying attention to this topic, and consciously undertaking team development, is well worth the effort.

The extent to which suppliers should be brought into the team will depend firstly on the nature of the contractual relationship (are they simply supplying something out of a catalogue or designing something bespoke?) and secondly the preferences of the lead company for supplier partnership. A hands‐off relationship with suppliers does not go well with technical partnership. A further variable is introduced when partners are of different nationalities. The way that different nationalities operate can often lead to unnecessary misunderstanding, another aspect of human dynamics worthy of attention.

The leadership of development teams is a very important role and one which requires a particular mix of skills: proactive out‐and‐about attitude, meeting people, reacting quickly and being highly communicative, dealing with issues competently and quickly. It is not a role where the person concerned can hide in an office. Other roles require somewhat different mixes of personality traits and there are several models of personality that can be used to match the individual to the role, where there is the flexibility to do so.

It can be seen that some attention needs to be paid to selecting people for development roles and a structured approach to this topic (there is more detail in Chapter 11) improves the likelihood of making good selections. Personal development is also an extremely important topic and is principally gained through project experience, ideally supported by guidance and mentoring. This is an area where individuals must take increasing responsibility, given the relatively short life of organisations and the relative absence of ‘jobs for life’.

In summary, human dynamics plays an important part in the running of engineering activities, which are often complex endeavours, undertaken by groups varying in size from a small handful to several thousands. As always, the technology leader has to take a pragmatic view of how to develop and use an understanding of these complex topics.

14.12 Critical Thinking

Decision‐making and problem‐solving are central to technology development work. Decisions or choices have frequently to be made, under pressure, with imperfect information. These decisions in this field may also have long‐term consequences, given that many products last for 10–30 years. Proficiency in ‘critical thinking’ is therefore an important quality in arriving at good decisions. It requires a focus on: formulating problems, gathering data, weighing alternatives, and reaching sound conclusions with an eye to statistical thinking.

Even without these pressures, decision‐making is subject to a wide range of human foibles, biases, and fallibilities. There are about six well‐described biases that affect human decision‐making; for example, the confirmation bias leads us to note information that supports our point of view but that subconsciously filters out information which does not do so. Awareness of these biases is helpful in reaching the best decision, especially when under pressure. There should also be an awareness that there are two distinct thinking modes – one is fast and is designed to make quick decisions to avoid danger whilst the second is slow and considered. Fast decisions have their place, but they tend to be somewhat imperfect.

There are also clear differences between the mind‐sets of different nations, with the West being driven by explicit logic and the East being more open to ambiguity. A combination of both approaches is the ideal in this field of work. At the same time, when working with different nationalities, it must be appreciated that significant cultural differences exist between different countries, companies, and individuals.

Framing and structuring a problem or decision in the right way is the first step to improve the quality of the process. There are some simple methods, such as the A3 structure described in Chapter 12, which can be used to pursue problems to logical conclusions and to involve a wider team in the process to broaden the experience brought to bear on the problem. There are also methods of creative problem‐solving, such as TRIZ, which can be used to guide more creative work, usually in the earlier stages of technology or product development.

Statistically based methods have had a big impact on manufacturing effectiveness, improving quality and consistency, and reducing cost. There are areas of product development where the same is possible; for example, in analysing customer data‐sets or reliability or warranty information. However, sample sizes during, for example, laboratory or prototype testing are likely to be quite small. There are however methods of analysing trends even with small sample sizes and, more importantly, applying the principles of statistical thinking.

For everyone involved in work of this type, some study of this topic is likely to be beneficial. As always, there is a trade‐off between quality and speed. However, competence and structure in decision making is likely to yield better decisions in less time.

14.13 Improving Product Development Performance

Having laid out in the earlier parts of this book how the processes for developing new technologies and new products should be approached, the question then arises as to how companies should set up effective systems or should tackle the improvement of their current systems.

For early‐stage companies – start‐ups or spin‐outs, for example – there will be no well‐established product development system in place and the concentration of effort will be on developing new technologies and their applications. They should do this in a way that lays the right foundations for future work. This can be done by paying particular attention to such areas as formally recording all engineering data, results, and reports, gaining an early understanding of manufacturing and supply implications, understanding the market, costs, and business drivers for the new technology, putting in place systems for recording learning points, and planning the structure of future phases of work, especially timescales and costs.

Established companies wishing to improve their product development systems should consider a well‐structured improvement process. Several models for this exist and an eight‐step process is described in the main body of the book. An important point to bear in mind is that developing new technologies and products is a company‐wide activity that has a huge bearing on the future progress of an organisation. It is not confined to one department – ‘engineering’. With wide involvement across an organisation, long‐term success will only be achieved with clear and determined vision and leadership. This needs to be accompanied by effective communication and some level of training for all involved.

The improvement process itself can include a number of short‐term projects, which should produce early results, combined with long‐term strategic projects. A good start point is a diagnostic survey of the existing system; a potential structure for this is described.

Achieving permanent results will depend on there being a receptive and supportive culture within the organisation, or moving the culture so that this is the case. Otherwise, progress can easily be lost.

However, the potential gains are well worth the effort. An effective system for developing technology and products is a tremendous competitive weapon that other companies will struggle to copy.