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:
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.
The output from this phase of work fully defines the product, enabling it to be built, operated, serviced, and retired. The engineering information includes:
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.
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.
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.
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:
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.
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:
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).
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:
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!
All engineering programmes rely to an extent on specialised resources in the form either of people or facilities. More specifically, these resources could include:
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:
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.
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).
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:
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.
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:
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.
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.
Current Estimate | Previous Estimate | Target | ||
Material | ||||
Direct labour | ||||
Total direct costs | ||||
Product‐specific investment | ||||
Commentary |
Figure 9.4 Tracking of product cost information.
Continuous reporting of financial data and projected sales volumes enables problems to be highlighted early so that management can take action.
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.
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.
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.
PROJECT A | PROJECT B | |
1. Company drivers | Driven by quality and processes | Driven by deadlines and costs |
2. Company culture | Co‐operative, shared goals | Inter‐departmental rivalry, over‐the‐wall mentality |
3. Market need | Very clear need identified and approved by customer | Very clear need identified and approved by customer |
4. New technology | Limited new technology; new elements pre‐tested | Much technology new to industry but used in other industries; very limited pre‐testing or early manufacturing work |
5. Product definition | High‐level performance specification from client | High‐level performance and detailed design, performance and other specifications from client, much information, some contradictory |
6. Design information | Single design authority, common bills of material, common technical specification, built to drawing. Cooperative change management process | Single design authority but, multiple bills of material, technical specification mainly from client, design continually questioned by client, major manufacturing deviations from drawing |
7. Calculation, modelling & simulation work | Thorough engineering analysis | Thorough engineering analysis |
8. Physical testing | Comprehensive programme with multiple prototypes resulting in many detailed changes; followed by competitive trials by client | Very limited programme |
9. Manufacturing planning | Detailed design‐for‐manufacture reviews | Very limited reviews, poor adherence to drawing |
10. Supplier management | Cooperative and constructive relationship | Contractual relationship |
11. Service performance | Minor problems in service | Multiple service problems; major, lengthy and expensive programme of rework |
12. Customer satisfaction | High satisfaction, product profitable |
Very low satisfaction, disputes about responsibility, legal claims and counter‐claims, compensation claims. Unhelpful newspaper publicity. But product eventually performed well! |
Figure 9.5 Outcome of two engineering projects.
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.
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.
This reference describes the growing importance of intellectual property in modern economies:
This reference describes how detailed design can be achieved:
Don Reinertsen, amongst other points, draws a comparison between military work and engineering programmes.
His first book, originally published in the 1980s, is one of the first books to look at the product development process in the round:
Westrick and Cooper's book has a plethora of practical guidance, based on experience, about how to run engineering programmes:
3.15.189.199