9.1 Introduction

This chapter is concerned with the final stages of technology and product development programmes. This is where the ideas that emerged several phases previously make their way into production and operation.

Taking a somewhat narrow view, and perhaps understating all the creative thinking that has gone previously, the final output of these development programmes is information. For the parent organisation, this is the information from which reliable new products can be manufactured, sold, and operated. This chapter describes how this information is finalised and delivered to its users.

As has been stressed elsewhere, this development and provision of information is not an ‘over‐the‐wall’ affair but a collaborative exercise where the product development engineers work closely with people in:

• Manufacturing
• Purchasing and supply chain management
• Service and product support
• Marketing

The engineers are the custodians of the product information, developed jointly by this group. It represents a critical, intangible asset of an organisation, despite the fact that it will not be financially recognised on that organisation's balance sheet. As an aside, investments in intangible assets now outnumber conventional asset investments in at least three countries (Sweden, United States, and United Kingdom) – see Ref. 1. They also have the advantage of being far more scalable – i.e. they can be used at increasing volumes, far more easily than physical assets.

This phase of activity corresponds to technology readiness levels 7 – 9, as described in Chapter 3, and manufacturing readiness levels from approximately MRL 5 and upwards. In terms of the stage‐gate model described in Chapter 5, the phase begins after the third review point and concludes at the fifth.

This phase consumes the majority of the cost of a development programme. It is where the bulk of the detailed designing, modelling, prototype manufacture, and test work are carried out. Earlier phases will involve all these activities as well, but at a much less intense level. At the conclusion of the phase, the various types of information will be in their final form, based on the feedback and learning from, for example, test work, manufacturing reviews, supplier discussions, and field trials, where these are relevant.

Given the number of people involved, perhaps across multiple organisations and locations, the number of engineering components, and the amount of data, it is a phase of work that does need significant structure and planning. Everyone needs to be clear about what is required and by when, in terms of major deadlines. However, there also needs to be a degree of flexibility, as learning and iteration are still prevalent to a degree; earlier, pre‐TRL 7 work should have given a solid foundation. There should not be any show‐stopping technology problems if the earlier work has been done thoroughly. However, detailed changes and vital improvements will come out on a daily basis.

The organisation undertaking this work is sometimes referred to as the company's design factory. There is an element of truth to this description, but factory management techniques, with one or two exceptions, definitely do not work in an environment where learning and iteration are still very much to the fore.

9.2 Forms of Information Output

The output from this phase of work fully defines the product, enabling it to be built, operated, serviced, and retired. The engineering information includes:

• Digital geometric models, usually in three‐dimensional form and from which conventional drawings can be derived.
• Bills of material, listing the parts, their formal part numbers and issue level, their quantities, and their assembly hierarchy. From this listing, manufacturing and supply sourcing routes can be derived and production scheduled. They also form the basis of cost models, weight estimates, and any other properties that require a complete parts‐listing.
• Written specifications for material properties, for example, or to define the performance requirements of parts, assemblies, and systems sourced as proprietary items, designed by their supplier.
• Product acceptance test and commissioning instructions.
• Regulatory documents, certificates and conformity documents.
• In some instances, safety cases or similar detailed documents to enable safety approval or formal acceptance by regulatory authorities.
• Physical operating models or prototypes that can be used for demonstration purposes.
• Operating, servicing, and fault‐finding instructions.
• Disposal or end‐of‐life instructions.

This information then forms the basis of manufacturing and procurement plans, which represent a further and substantial area of documentation including: production processes, factory layouts, quality management processes, and supplier management, to name a few, and not covered in any detail in this book. Figure 9.1 shows the scope of engineering information and the ‘delivery system’ for providing it to the company, suppliers, dealers, and customers. Not all companies will follow precisely the same pattern as shown on the diagram; some, for example, might not involve distributors. However, the principles still hold.

It is important to note that there should be one master source for each of the pieces of information defined above, probably with one controlling individual and all with formal version control. There are still, unfortunately, companies that run multiple bills of material, for example, which is a recipe for confusion and wasted effort. When electronic, international access to master databases is readily arranged, the multiple and unofficial lists, common some years ago, have no place in modern engineering. The basis of these disciplines should be created from the early stages of technology development – it is not just the province of the later, delivery stages of product development projects.

9.3 Connected Products – Internet of Things

Information connectivity to and from the manufacturer to operating products is becoming an increasingly important aspect of engineering, adding a further dimension to the diagram above. As well as designing sensors and data transmission systems into products, it will also require the portfolio of product information produced by the manufacturer to include software for data analysis. This, in turn, then prompts the need for guidance and instructions about how to interpret the data, what constitutes a faulty condition, for example, and what supporting service the customer then needs as a consequence. Internet of Things (IoT) opens up all sorts of interesting possibilities for which there must be a clear business case but which has the potential to add a new and valuable dimension to a manufacturer's offering.

9.4 Detailed Design

Concept development will have generated predominantly schematic layouts of the proposed technology or product. There will probably also be some individual component details, especially where tests on real items have taken place. The detailed design phase takes this starting point and produces complete engineering information, such as drawings, on all individual components, as well as how they fit into subsystems and systems. Whilst the concept fixes the cost envelope for a new product, the detailed design fixes costs and manufacturability at an item‐by‐item level.

In terms of cost, the difference between good and bad design can easily be ±20%/30%. Simpler designs provide cheaper and more elegant solutions, as well as greater reliability. Most component designs are attempting to balance a range of factors – function, cost, weight, appearance, and manufacturability are some examples. Basic calculations such as stress analyses will be used to evaluate components at this stage.

Components also interact with adjacent parts to which they are attached or are connected or which they must avoid contacting. This obviously places limitations on how the design can be achieved, and there is a constant juggling act to synchronise component designs. Once complete, designs can be assessed in terms of complexity indices, which look at the number of parts versus the number of functions in an assembly – see Stuart Pugh Total Design (Ref. 2).

The work relies, in particular, on good, basic engineering practice to generate workable, efficient solutions that meet the needs of customers and other interested parties.

9.5 Handling the Interfaces

Based on the detailed design work above, this phase of work is particularly characterised by the generation of high volumes of new and detailed information. This is partly a function of the greater number of people involved, and hence the quantity of work completed and partly the sheer breadth of activities being undertaken. New information and new issues will be continually generated by detailed design work, analysis and modelling, testing, manufacturing development, and supplier work. This is an inevitable and, for some, inconvenient truth. There would be no point in doing the work if this were not the case. How well an organisation deals with this situation is the acid test of its product development capability.

The focus is then on the decisions about how to respond to this new information. Some data may simply confirm what had already been assumed or planned, in which case no follow‐up action is required. Other information may suggest changes to avoid problems or to improve the product or its manufacturability, This, in turn, leads to discussions and decisions about:

• Whether and how to change the product definition
• Whether to re‐run the work, such as tests, which identified the potential change, with modified material
• What to do with material that has already been ordered or made to the previous standard
• What impact the potential change might have on costs, investments, and timescales

Each decision should be taken on its own merits, and there are no prescribed rules as to how this should be done, except to ensure that a full picture is assembled of the relevant facts before deciding what to do and that the decision should be taken collaboratively.

9.6 Cost of Delayed Programmes

A critical point to bear in mind in these situations is the scale of the potential cost of delay. In Chapter 4, attention was drawn to the high profitability and hence high financial returns from technology and product development programmes. The obvious consequence of a delayed product launch therefore is a high financial opportunity cost. Some companies can quantify this cost quite easily, whereas for others it may be less straightforward. Some examples are:

• Value of output well known. An example might be an oil refinery. If a refinery is being constructed with capacity of, say, 500 000 barrels per day, a quick calculation at $50/barrel suggests $12.5 m per day material going in and margins presumably measured in $100 k's or $m's per day. In this situation, delay is very expensive.
• Penalty clauses apply. Some contracts have liquidated damages clauses with penalties for each week of delay (contracts in this form are a sure recipe for poor quality and strained relations).
• Seasonal product. Some products must hit summer or Christmas markets. Even a few weeks' delay can result in lost sales and profitability through loss of a season's sales.
• Loss of profitability. New products are invariably planned as sources of new profitability. The value of delays can be quantified in terms of the lost profit opportunity as well as the additional cash flow exposure as a result of a longer development programme.

Every company could estimate the cost of project delay, if only in approximate terms. Such estimates invariably point to a preference for maintaining timescales, provided the product meets an acceptable sign‐off standard (see below).

9.7 Planning and Decision‐Making

The approach that can be taken to planning and managing all phases of technology and product development programmes has already been described in some detail in Chapter 5. The delivery phase of such programmes, the subject of this chapter, is the most complex, organisationally, and involves the most resources, much of which could be spread amongst different organisations and locations.

It therefore requires careful planning at the appropriate level of detail. Specifically, everyone involved needs to know what they have to do and by when. This does not mean, however, that planning must be overly complicated or bureaucratic. In fact, simplicity of planning is an essential aid to effective and clear communication to a large team.

The starting point is a high‐level master plan showing the overall timescales. This is likely to be driven by:

• Timing of the release of early engineering information, sufficient to start manufacturing planning and procurement
• Procurement timescales for long lead items
• Facility and investment lead times
• Lead times for establishing sales and service networks
• Lead times for establishing data networks
• Final engineering release based on validation work
• Judgement on the extent to which the procurement and investment activities can be overlapped with the engineering development

Each element of the project then needs its own subplan with key milestones. Those for engineering, manufacturing, and procurement need to go down to a part‐by‐part level (so a complete bill of material is vital). In most cases, the plan needs simply to be a list that can be ticked off as progress is made, rather than a complex network.

The programmes for other parts of a large project can take the form of milestone plans, linking back to the master plan.

Day‐to‐day management can then be handled at a team level where there will be constant review of progress, issues, learning points, and priorities. This topic has already been covered in Chapter 5 in Section 5.13, ‘Monitoring Small Projects or Sub‐Projects’. Above the level of the individual team, there should be a tight structure of less frequent, but timetabled, formal meetings, perhaps culminating in stage‐gate reviews. The aim always is to contain problems and deal with them flexibly and imaginatively.

Don Reinertsen, in his book The Principles of Product Development Flow (Ref. 3), draws a detailed comparison between engineering and military planning, as specifically practised by the US Marines. In the heat of war, the generals cannot control each individual unit or soldier directly. They lay out the overall plan, especially the objectives, and rely on the units having a good understanding of these objectives to take the initiative as the battle proceeds. In the military situation, the right balance must therefore be struck between central coordination and decentralised responsiveness. (See also Ref. 4.)

In engineering, new information, which is constantly emerging, is first visible to the front‐line engineers, who should adapt their tactics to respond to the new situation. The engineers should be trained and developed to work in this way. They must have the trust of the organisation to respond in the right way, plus the knowledge that the backup is available should problems escalate. Engineering therefore follows the same principles as the military, but with only reputational injury rather than physical injury at stake!

9.8 Specialised Resources

All engineering programmes rely to an extent on specialised resources in the form either of people or facilities. More specifically, these resources could include:

• Individuals with special knowledge and skills for development work
• Senior and experienced staff for technical reviews
• CAD facilities and software
• Computing facilities and software for analysis and modelling (computer‐aided engineering, CAE, resources)
• Manufacturing capabilities for making and assembling test components
• Test and data analysis facilities
• Senior managers, required to make decisions or formally sign‐off proposals

Within small organisations, with only one or two projects, some of these points may be less of an issue, but such organisations will depend more on external suppliers with whom they will have limited leverage. Large organisations will possess internally most of these capabilities but will be handling multiple projects with different priorities, competing for resources with each other.

The result of these bottlenecks is stoppage. It can be thought of as queues of part‐finished engineering work‐in‐progress (WIP). It is not physically visible, as is the case in a manufacturing plant with physical inventory, and it is not recorded as WIP in an organisation's accounts. Hence, it not managed directly – remember the adage, ‘What gets measured gets managed’.

If anything is measured in this situation, it is more likely to be utilisation of resources, which actually has the effect of increasing bottlenecks. (Queuing theory shows that, as utilisation increases so do queue lengths, alarmingly so as 80% + utilisation figures are achieved – see Figure 9.2.)

The point is that bottlenecks of specialised resources can have a huge effect on product development throughput times and in slowing down the important feedback loops, which are at the heart of the process. In many situations, it is an invisible and unmeasured constraint on progress.

In terms of what can be done, the following are suggested:

• Understand that this problem exists.
• Try to increase the level of resource in known bottlenecks – easier said than done.
• Reduce discretionary workload on bottlenecks and hence reduce their utilisation.
• Find ways of reducing the work content of tasks assigned to bottlenecks, concentrating on what absolutely must be done by specialist resources.
• Train general engineers to be capable of doing at least some of the bottleneck work.
• Book external facilities well ahead of the point of need.

The reason that projects can often be accelerated when given management attention is that those projects jump the queue in these bottleneck areas. The real test of product development management is whether cycle times for all projects, not just the priority ones, can be improved.

9.9 Flow of Information

The topic of specialised resources highlights one area where a direct parallel can be drawn with lean manufacturing. Engineering work is rather like material in a (poorly organised) factory, criss‐crossing from one workstation to another. A plot of the time components spent travelling, waiting, and being worked on will show limited value‐added time but much wasted time. The same principles can be applied to engineering WIP. One of the advantages of project‐based organisations (see Chapter 5) is the tightening of these flows. Drawing on manufacturing practice, it is perfectly possible to set up classic U‐shaped cells for engineering work, as in Figure 9.3.

The membership of such cells can be expanded, e.g. to include analysis or test engineers, or contracted to suit the situation. They could be staffed permanently or people could get together for a few days a week then return to their normal base (this is one way of creating a hybrid between the functional and project style of organisation – see Chapter 5).

9.10 The Importance of Good Systems

Whilst face‐to‐face contact and discussion is the most effective means of taking product development forward, it needs to be underpinned by good systems, especially in two areas:

• Product data. Design information, parts lists, specifications, product acceptance tests
• Engineering process management information. Progress tracking, change control, and learning points

The key point about the first of these is that the most up‐to‐date and comprehensive product and process information should be widely available to the development team – something that is entirely possible, technically.

In terms of process management, Chapter 2 (Engineering as a Process) described two processes that are critical to the development process – change management and recording problems or learning points. Both need to be tracked so everyone is clear about progress, what is still open, and what has been closed.

9.11 The Role of Standards and Design Codes

Standards and design codes play an important role in ensuring the integrity and reliability of new designs. In many industries, longstanding international standards exist that in effect represent the collective wisdom of generations of engineers working in the field concerned. Examples can be found in construction, pressure vessels, process industries, automotive, and aerospace, to name but a few. They are particularly important in relation to integrity and factors of safety where long experience has shown what will and won't work safely. They may also underpin certification or regulatory approval.

The derivation of such standards is often therefore empirical, based on observation rather than logical calculation. This reflects the fact that patterns of usage, duty cycles, and abuse are often difficult to define precisely although modelling and calculation is used to back up more intuitive conclusions. There are also more general standards on test methods, materials, laboratory methods, terminology, and management systems. Organisations such as ISO, SAE, ASME, BSI, and CEN (see Glossary) have the most comprehensive libraries of standards.

Where standards already exist, and there is no field of engineering where this is not the case, companies developing new technologies or products should clearly use them. However, when it comes to the detail of new configurations of technologies and products, new methods of design will be generated by the originating organisation. These new product‐specific methods represent critical intellectual property that should be written into company design codes (‘how‐to’ documents) that enable the technology to be reproduced. Such codes will be a mixture of calculation methods, assumptions, test methods, and relevant existing codes. Taking a simple example, a design code for a cooling system might include:

• Operating environment assumptions, e.g. temperature and humidity range
• Calculation methods or models, which could be coded as software
• Materials standards
• Tolerance to off‐design conditions, e.g. heat exchangers partly blocked, coolant level low, sensor inaccuracy, incorrect antifreeze, or inhibitor concentration
• Safety shut‐down approach
• Test and sign‐off methods
• Relevant international standards
• Maintenance assumptions
• Effect of loss of electrical power during normal operation

Well‐established companies have libraries of design codes and standards of this type representing an often‐underestimated repository of company learning. New companies should think in terms of developing new design codes to document their learning, something investors also should encourage.

9.12 Tracking Product Cost and Investment

The points above are mainly concerned with the technical development of products and their performance. But as stressed in Chapter 4, new technology needs to be commercially as well as technically successful if it is to be of any value. An important part of the programme, therefore, is to ensure that all financial targets (product cost, labour content, investment, and operating costs) and sales volumes are met.

This is best done by tracking on a part‐by‐part basis from the earliest possible stage – see Figure 9.4. Apart from ensuring accuracy and completeness, this also devolves responsibility, enabling costs and related topics to be managed alongside ‘engineering’ parameters.

Continuous reporting of financial data and projected sales volumes enables problems to be highlighted early so that management can take action.

9.13 Knowing When to Stop

There then comes a point when improvement may have to stop. If the development programme throws up issues that simply must be dealt with, e.g. to achieve legal compliance or to avoid problems in service, then delay or additional cost may have to be accepted. Where there is some discretion about potential changes, then the high cost of delay comes into play, and it is often better to continue with what already exists rather than incorporate further improvements.

Seasoned engineers frequently use the expression ‘the better is the enemy of the good’ for guidance at this point. They probably don't realise that, in doing so, they are drawing on the wisdom of the past. In Shakespeare's King Lear, the Duke of Albany said, ‘Striving to better, oft we mar what's well’ and Voltaire ascribed his statement that ‘le mieux est l'ennemi du bien’ (i.e. ‘the best is the enemy of the good’) to an Italian sage.

One of the important roles of the project leader in this situation is to bring product development to a halt and move into the production phase. In some companies, there may be a formal process for doing this, as described next.

9.14 Signing Off the Product

A good discipline in the concluding stages of a product development project is to have a formal process of sign‐off and ‘release’. The objective is to confirm that the product, having completed its programme of development, is in a fit state to be manufactured and sold. The process revolves around doublechecking that all requirements have been met, all concerns have been answered, and, as far as possible, nothing has been missed so there are no loose ends.

This could mean looking through all the risks identified, analysis reports, test reports, design‐for‐manufacture studies, and corrective action records to confirm that all have been cleared. To a certain extent, systems can be developed for keeping a running record of these points, and this is perfectly possible when validation work has shown a clear pass or fail. However, there will be situations when requirements have not been fully met and development work or design‐for‐manufacture has shown a trade‐off between requirements, rather than a black‐or‐white result. Alternatively, there may have been solutions proposed to previous problems, which are still undergoing durability tests. Customer requirements also develop over time: new ones may emerge and some previous ones may reduce in importance.

Judgement may therefore need to be exercised as to whether to continue to enter the production phase or whether to pause. The ideal decision would be ‘OK for production and sale’ but decisions could be in the form of ‘OK to start production but not released for sale’ or ‘OK to produce a certain quantity’. The worst outcome is ‘Delay production for xx weeks’. These are topics that could be taken by a stage‐gate review board, based on the input from the project's engineering leader.

9.15 Examples of Good and Bad Practice

To put the foregoing into context, Figure 9.5 summarises the key points about two contrasting projects from the author's direct experience. They are both real‐life projects involving relatively complex, engineered products. As it happens, both were projects won through a bidding process to single customers, rather than direct sale to multiple customers, but this is not relevant either to the way the projects were run or to their outcome.

The contrast between these two projects, executed within a few years of each other, could not be clearer, in the eyes of both the suppliers and the customers. The first 10 points above are the inputs to the process and 11 and 12 are the outputs. This suggests that careful attention to these 10 points is the key to developing a strong capability in the delivery cycle of new product development. Ref. 5 also provides some useful guidance.

9.16 Concluding Points

This chapter has covered the detailed engineering phase of new product development projects, including the preparatory stages for production, which are important to developing the manufacturability of the product. At the end of this phase, a commitment is made to series production. It is the most resource‐intensive part of new product programmes, involving all areas of an organisation who must cooperate in bringing the product to successful fruition.

The output of the engineering programme is technical information – drawings, parts lists, specifications, and regulatory material, for example. Describing this output merely as information underplays its significance, given all the effort and creativity that has gone into it. However, this information is a major corporate asset, easily comparable with physical assets in terms of its importance and therefore deserving adequate protection.

The success of this phase of work is very dependent on what has gone previously. New technology should have been matured to at least TRL 6. Similarly, there should be a strong and well‐researched marketing requirement and a good business case. Without this foundation, problems will certainly arise in terms of cost, quality, and timescales.

It is a highly cooperative activity. Given the number of people involved, planning and coordination are critical, but both need to be done in a way that recognises devolvement of decision‐making (it is impracticable to centralise this, and it would slow the cycle substantially). Product development work throws up problems, issues, and learning points at an alarming rate, but the bulk of these can be dealt with at the level of the team through frequent interactions and cooperative working. Physical proximity makes this much easier. Some problems, though, may have to be escalated, so structures to facilitate this should be in place.

A particular focus should be placed on ‘bottleneck’ activities, which usually revolve around specialist, or difficult to access, people and facilities. They can dictate the overall pace of progress, involving long but invisible queues of work waiting to be done.

Product cost, investment, and sales volumes should be tracked and updated throughout the programme to make sure that these important parameters are where they should be.

At the end of the phase, the wish to improve the product still further may have to be curtailed but, at the same time, it is sensible to conduct a full, formal review to confirm that the product is fit‐for‐purpose.

Finally, a brief summary is given of two contrasting projects from the author's direct experience. The 10 critical features of these two projects form a good guide to what makes a project successful or unsuccessful.

References

This reference describes the growing importance of intellectual property in modern economies:

1. 1 Haskel, J. and Westlake, S. (2017). Capitalism Without Capital: The Rise of the Intangible Economy. Princeton, NJ: Princeton University Press.

This reference describes how detailed design can be achieved:

1. 2 Pugh, S. (1991). Total Design: Integrated Methods for Successful Product Engineering. Reading, MA: Addison‐Wesley.

Don Reinertsen, amongst other points, draws a comparison between military work and engineering programmes.

1. 3 Reinertsen, D.G. (2009). The Principles of Product Development Flow. Redondo Beach, CA: Celeritas Publishing.

His first book, originally published in the 1980s, is one of the first books to look at the product development process in the round:

1. 4 Smith, P.G. and Reinertsen, D.G. (1997). Developing Products in Half the Time Second Edition New Rules, New Tools. New York, Wiley.

Westrick and Cooper's book has a plethora of practical guidance, based on experience, about how to run engineering programmes:

1. 5 Westrick, R. and Cooper, C. (2012). Winning by Design: Practical Application of Lean Principles for Transforming the Speed to Market, the Quality, and the Costs of New Product Development. Create Space Independent Publishing Platform.