13.1 Introduction

The previous chapters in this book have been concerned with the approaches and methods for developing new technologies or new products. They have laid out the framework within which this economically important activity should be structured and managed. New or emerging organisations can use the preceding material to help them start on their journeys and, hopefully, achieve results more quickly. However, most organisations are not starting with a blank piece of paper. They already have programmes of work in this area and are asking the question, ‘How can we improve our product development performance’?

The art of bringing about ‘improvement’ or ‘change’ is a well‐researched topic. There are many formulae on offer and the many experts on the subject point out that most change initiatives unfortunately fail. Initiatives in the field of product development are no exception to this point and arguably are more difficult to undertake given the long timescales of the activity and the intangible nature of the work.

However, the potential rewards are considerable: an effective technology and product development system is a tremendous competitive advantage that other companies will find difficult to replicate. It is also possible to build up improvements in performance over time, based on a combination of small‐scale, local improvements alongside strategic, company‐wide programmes. As with most initiatives in business, persistence and determination are the most important factors.

This chapter suggests how organisations might approach this task.

13.2 What Type of Organisation Are We Dealing With?

Organisations working in the technology and product development field vary from the small start‐up to the large, well‐established corporation. Their activities also range across the technology maturity scale. This is illustrated in Figure 13.1.

As can be seen, an organisation might be a:

• Research group, such as in a university
• Start‐up or spin‐out company
• Established but developing company
• Large, well‐established organisations

Each of the different types of organisation can improve its product development performance but the focus of improvement efforts will be different, in line with the role and maturity of that organisation.

The material in this chapter provides guidance on improving business performance generally, but with an emphasis on technology and product development activities. Large organisations will need structure and planning to be effective. Small organisations can use the same principles but can act in a more agile fashion.

13.3 Structuring Improvement and Change Initiatives

There are many ways of managing improvement programmes. The author has direct experience of several, laid out as a series of steps varying in number from about 5 to 14. It is good to have a systematic approach, and the eight‐step model proposed by John P. Kotter (Ref. 1) of Harvard Business School can be very effective:

1. Establish a sense of urgency.
2. Create the guiding coalition.
3. Develop a vision and strategy.
4. Communicate the change vision.
5. Empower employees for broad‐based action.
6. Generate short‐term wins.
7. Consolidate gains and produce more change.
8. Anchor new approaches in the culture.

The model is aimed at larger corporations, but its principles can be applied by any size of organisation.

13.4 Diagnosing the Current Situation – Generating Urgency

A good first step is to understand the strengths and weaknesses of the organisation's current technology and product development systems and use this as a start point for the improvement programme. This will provide a focus for the work and therefore help the organisation to bring a sense of purpose, which, in turn, will drive urgency based on potential results. Figure 13.2 provides a framework for understanding the current situation in a company.

The primary relevance of this grid is to established companies, but it does also point out the trajectories that developing companies might inadvertently follow, if they do not make a conscious effort to do otherwise. The idea of this grid came from the Quality Maturity Grid in the well‐known book by Philip Crosby, Quality Is Free, published as long ago as 1979 (Ref. 2). The main usefulness of the grid is in promoting discussion, rather than being a rigid and absolute tool.

Having understood in qualitative terms an organisation's current situation, or where it could potentially be, it is helpful to creating urgency and purpose if some quantitative evidence could also be estimated. This could include:

• Typical product development cycle times compared with competition
• Lost sales or profitability due to slow or late launches
• Additional cash requirements due to longer cycle times
• Missed seasonal launch opportunities

A combination of qualitative and quantitative evidence describing current inefficiencies is a powerful way of communicating the urgent need to improve to all levels of an organisation from its CEO through to its junior staff. It also provides a means of measuring future progress.

13.5 Organising a Way Forward – The Leadership Role

Any significant improvement programme needs to have full management involvement and support if it is to have strategic impact over a long period of time – one of the golden rules of change management. This is especially the case with product development activities, given the cross‐functional nature of the process. Change will need the active involvement of engineering, manufacturing, purchasing, and marketing activities as a minimum. The most serious mistake is to see such a programme as the ‘engineering department's problem’.

A ‘guiding coalition’, to use John Kotter's terminology, would have the managerially oriented role of:

• Formulating objectives
• Agreeing priorities
• Assigning people and funding
• Planning the programme
• Reviewing progress

More importantly, it has the leadership role of:

• Creating a vision
• Communicating
• Addressing roadblocks
• Overcoming complacency
• Creating trust
• Celebrating success

The most important attribute of this team is a desire to improve the organisation's performance in the field of technology and product development as a means of enhancing the company's competitiveness. They must then communicate this commitment to their organisation.

13.6 Developing the Strategy and Vision

Any good change initiative or programme is guided by a clear statement of purpose – its vision – laying out what the future should look like, why it would be beneficial to the company, and how it would support customers, employees, and stakeholders. The vision needs to be ambitious but achievable and not couched in overly grandiose or unrealistic terms. Equally, the vision should be neither too vague and unspecific nor so detailed as to limit initiative. A good length is five to six sentences and 100–120 words.

For an initiative directed towards technology and product development work, the vision could include specific reference to topics such as:

• Cycle time to develop new products
• Number of new products entering service
• Reliability of products entering service
• Company spend on research, technology, and product development

By clarifying the direction for change, it should overcome disputes about this direction, although this will only work if the vision is developed as a collaborative exercise rather than being imposed.

It should act as a source of motivation, especially to those who might be disadvantaged by change, at least in the short term. It should also help people to work out for themselves what needs to be done in their area of operation, rather than being expected to be told what to do.

Vision statements are normally associated with broadly based company change initiatives of which improving the product development processes might be part. However, they are just as relevant to something focussed on product development, which would be a wide‐ranging initiative anyway, with multiple participants.

Involving many employees in developing the vision promotes a sense of participation and will improve the content of the vision statement. Another helpful way of improving it is to write a longer version, perhaps several pages, through the same process and then go back to the short version for a final edit.

This approach might seem overelaborate for a small organisation with a handful of people. The same process can, however, be easily and quickly followed as a means of clarifying everyone's thinking. It might also be useful in communications with investors or lenders, giving them confidence about the way forward.

It is worth spending some time on this topic, thus doing a thorough job and not being tempted to short‐cut the process. In doing so, the words of Gary Hamel (Ref. 3), said in the context of strategy, are pertinent:

Create new passions! In the past, we've driven the emotions out of (strategy). The field is dominated by those who trained as economists and engineers – the two disciplines which have the least grasp of what it means to be a human being.

13.7 Communicating the Vision

A wide‐as‐possible understanding of the initiative is clearly vital, whatever the size of the organisation. If it is not done properly, people will make their own, usually erroneous, assumptions. Communication is often thought of in terms of briefing meetings, notice boards, intranets, and newsletters. There is a place for these, but they are amongst the weakest means of communications as they lack human content and may be perceived as corporate propaganda. However, some effort is suggested in this area.

It helps, of course, if the message can be expressed in simple, straightforward terms, and there is no harm in frequent repetition.

There are then three ways of communicating the intent more strongly:

1. Training. Everyone (absolutely everyone) involved or affected can be given training or awareness about what is planned: its purpose and objectives, the principles on which it is based, the plan of action, the expected results, and the changes required. This is especially powerful if the training is given in person by line management.
2. Incorporating into everyday discussions. Rather than being somehow a separate activity, the improvement programme can be built into everyday activities, interactions, and discussions.
3. Management behaviour. The real test from an employee's viewpoint is how management behaviour actually changes (not how it says it is going to change). For example, if the company has a history of releasing underdeveloped products onto the market, then postponing a launch until the product is right, at some cost or embarrassment, would be taken as a real signal of intent.

The overall tendency is to underestimate what is needed in the area of communicating the vision, and few managers have the charisma to influence solely through charm and personality. However, leadership by example will overcome much of this.

13.8 Empowering the Organisation

Improving product development performance usually involves speeding up cycle times, placing greater emphasis on risk identification, and seeking a better‐optimised product. This, in turn, requires, or brings about, greater devolution of responsibility, and hence more initiative at the working level, with less dependence on supervisory action. It almost certainly will involve greater teamwork among people from different specialisations within an organisation. The term empowerment is sometimes used to describe this change –a description that reeks of management‐speak but that is nonetheless accurate.

Bringing about such significant changes will need the active involvement of a wide range of people. Quite often, barriers to change appear at this point, either consciously or unconsciously, as people defend the status quo and their own ‘territory’.

One of the biggest obstacles of this type is often the area of cross‐functional working, which is fundamental to successful product development projects. For example, a wish to select the lowest purchase cost, a typical target for purchasing departments, may conflict with product performance, cycle time, or manufacturing efficiency; having to escalate trade‐off decisions some way up an organisation will either slow progress or result in no decision at all.

Another source of problems may be management information systems that emphasise the wrong parameters or fail to measure the right parameters at all. Incentive, appraisal, and personal performance systems may also encourage the wrong approach.

Middle management activities also often have to change, usually from a supervisory, decision‐making to a coaching, facilitation, and unblocking role, which may stretch the capabilities and natural skill sets of those involved. These requirements place more emphasis on social, influencing, and behavioural aspects of those involved, rather than largely technical skill sets. Many will require help and coaching of their own to achieve such changes and, for some, it may be too much. These are issues better confronted than left to fester.

The overall point is that, no matter how well the vision is communicated, improving product development performance will require changes to how people operate at the working level, how they are led and supervised, and how they are measured and rewarded. Improvement programmes will therefore require strong and determined leadership if they are to have significant impact.

13.9 Generating Short‐Term Wins

Few change initiatives, no matter how well thought out or communicated, can survive for long without some tangible evidence of progress. This is a natural consequence of human scepticism and impatience about business change programmes. It affects both employees, although some will maintain their optimism, and investors, whether they are corporate headquarters in the case of large organisations or private investors in the case of smaller companies.

Fortunately, there are many opportunities for small‐scale, short‐term projects that can both produce useful results and provide evidence of progress. With a little guidance, staff involved in the improvement initiative will come forward with many useful ideas based on their practical experience of how processes currently run and what problems they experience.

Ideas for such projects include:

• Co‐locating a small cross‐functional team into a project cell to tackle a difficult issue affecting a live project
• Trying a manufacturing and purchasing review of a developing project at a much earlier stage than normal
• Undertaking a technology readiness level (TRL)/manufacturing readiness level (MRL) assessment of a technology project and then acting on the results
• Doing a quality function deployment (QFD) review on an early‐stage project
• Putting together a cross‐functional team to improve the product change management process
• Doing a virtual reality servicing assessment of a product at the design stage
• Undertaking a formal and thorough project sign‐off before launch
• Reliability testing, with an adequate sample size, of a new product ahead of launch
• Undertaking an early‐stage product risk and safety review

Every organisation should be able to find a number of projects of this nature to kickstart the improvement process. The diagnostic activity described above is another source of proposals. Ideally, the projects should involve several areas of the company, including those who do not frequently work together. Such groups will benefit from coaching in problem solving and some initial team building. From this point of view, small projects can be seen as building capability as well as achieving useful results.

Success in the short‐term provides evidence of progress and rewards the effort of those involved, thus building momentum and confidence within the organisation. It will help set the direction for future work by identifying areas where the company can achieve results and how they should organise to do so.

It will also be helpful in building confidence from external stakeholders, such as investors, although care must be taken to provide evidence of business performance improvement and not just interesting activity. If tangible results can be shown, these stakeholders will ask for more!

13.10 Longer‐Term, Permanent Change

The short‐term changes already mentioned will make a useful contribution to the progress of an organisation but will not address root‐and‐branch improvement in product development performance. A series of small projects will, however, provide good evidence of what further needs to be undertaken and what, more fundamentally, is needed to improve product development competitiveness. They will also provide experience of issues around human aspects of change, especially why people find change difficult and where the roadblocks might be.

From this start point, organisations then need to step up a gear to take on more strategic and fundamental changes. This could be done as a series of projects but over a longer period and with more ambitious objectives. In terms of the projects that could be considered, the following are suggested:

• Structuring of major projects. Placing more resource onto early‐stage cross‐functional activities
• Organisational model. Moving away from a functional to a project structure
• Partnering. Much closer working between engineering and manufacturing/supply chain partners
• Facilities. Investing in improved facilities for analysis and testing
• Technology programmes. Building a portfolio of new technologies, developed ahead of specific product programmes
• Customers. More early‐stage involvement from customers
• Whole life. Building up knowledge and experience to understand what is needed for whole‐life and connected support of products

Projects of this type provide the mechanics – the systems and processes – for better performance. Human aspects, however, are likely to be just as challenging. As has been noted throughout this book, technology and especially product development are highly collaborative activities. They need input from engineers, marketing people, customers, suppliers, and manufacturing experts, plus others. The easiest way of managing these inputs is as a linear series of activities: the customer specifies what he wants, the marketer consolidates it, the engineer works out a solution, the manufacturer makes it, and so on.

This process gives everyone neat and independent tasks against which they can be measured. Unfortunately, this process does not work. It is too slow to be competitive, and it makes optimisation difficult. If what the customer wants cannot be made cost‐effectively, then the cycle starts again, usually amidst a bout of recrimination.

The challenge of bringing about permanent change is the challenge of getting people to work together collaboratively, parallel processing information but within a structured framework. This approach is not something that can be readily imposed; it has to grow within an organisation.

Leadership of fundamental change must therefore provide the conditions for new capabilities to flow but must also let the organisation do the work for itself. As noted above, leadership in this situation is concerned with creating and communicating a vision, overcoming roadblocks and complacency, creating trust, and celebrating success.

13.11 Achieving Permanence

The final question is: how can these changes and improvements be made permanent? The question arises because experience shows that changes of this type can easily regress if the pressure is taken off. Priorities change and people in leadership positions move on, resulting in the emphasis moving elsewhere.

Some of the suggestions made above, such as investing in new facilities and capabilities, will have an obvious permanence and are unlikely to fall into disuse. It is also possible, at least in theory, to write new ways of working into documented procedures – the formal quality systems that organisations of the type described will almost certainly have. However, such procedures cannot readily mandate the constructive and cooperative working, which product development requires. These depend more on the way that people work together than on the processes written down in corporate manuals.

The issue centres on the culture of the organisation. This involves the behavioural norms and shared values of the organisation, which are usually an invisible product of its past. It concerns the pervasive ways of acting in an organisation. New organisations can deliberately create their own cultures, although the result is as much influenced by the background and style of the founders as it is by conscious design. In existing organisations, culture will have been established and reinforced over time. People will have been subconsciously recruited with similar values to those already prevailing, then guided and mentored in those values. Those who are promoted will hold similar values.

All will be well if the existing values support the improved product development approach. Problems will arise if this is not the case. For example, problems will already have been encountered if the prevailing culture was risk averse, political, and slow. Similarly, if managers ran their own independent fiefdoms, then collaboration will already have been found to be difficult. Responsiveness to customers is another critical area.

Achieving permanence for change therefore requires careful attention to the culture of the organisation. In a change programme, it is arguably the last area to change because it depends on first achieving successful results, and it is not something that can be imposed. The key point is that for an improvement or transformation programme to be successful, the changes must be anchored in the organisation's culture. This is especially the case in the area of technology and product development, given the cross‐departmental and interpersonal nature of the work.

13.12 Model of Good Practice – Toyota Product Development System

Some leading companies have the reputation of having built up more effective processes than others in developing new products and could therefore be considered as models of good practice from which other companies could learn. Toyota is one example of this category, as measured, for example by its time to market for new products, which was, before its competitors started to learn from Toyota, some 60% faster than the norm.

It is, of course, more well known for its Toyota Production System (TPS), developed during the 1950s, 1960s, and 1970s and made more public from the 1990s onwards. The thinking behind TPS has had a profound influence on manufacturing worldwide.

Their product development system uses similar, waste‐avoidance principles but noting, of course, that the ‘materials’ of product development are information rather than the physical products of the manufacturing world. Their product development system is well documented, not by Toyota itself but by two American authors in the book The Toyota Product Development System: Integrating People, Process and Technology by James M. Morgan and Jeffrey K. Liker (Ref. 4).

The authors identify 13 principles on which the Toyota Product Development System is built:

1. Establish customer‐defined value to distinguish value‐added activity from waste.
2. Front‐load the product development process while there is maximum opportunity to explore alternate solutions thoroughly.
3. Create a levelled product development process flow.
4. Utilise rigorous standardisation to reduce variation and create flexibility and predictable outcomes.
5. Develop a chief engineer system to integrate development from start to finish.
6. Organise to balance functional expertise and cross‐functional integration.
7. Develop towering technical competence in all engineers.
8. Fully integrate suppliers into the product development system.
9. Build in learning and continuous improvement.
10. Build a culture to support excellence and relentless improvement.
11. Adapt technology to fit people and process.
12. Align the organisation through simple, visual communication.
13. Use powerful tools for standardisation and organisational learning.

Most of these points are covered elsewhere in this book, albeit using somewhat different language in many instances. In Appendix 2, there is further expansion of the points above and a cross‐reference between each of the 13 points and the relevant section of this book. In context of change management and improving the product development performance of a company, the Toyota system forms a good model, although one that is not easy to copy given that many of the 13 points above relate to the ‘softer’, cultural aspects of business rather than more tangible or physical activities.

13.13 Models of Good Practice – Agile Software Development

So‐called agile methods of software development are another source of ideas and models of good practice, which can be transposed into the world of for engineering. Although the word agile can be somewhat overused, and may smack of a management fad, agile software development methods are well documented and address many of the same issues that face engineering product development. Of course, many, if not most, engineering products contain software in some form anyway, so there is a direct link from that point of view.

The origins of the approach can be traced back to the Manifesto for Agile Software Development of 2001 (Ref. 5), which was a reaction to what, at the time, were seen as overly rigid and micromanaged methods of running software programmes. The approach places emphasis on self‐organising and small cross‐functional teams, adaptive planning methods, continuous customer collaboration, and delivery of working software in short bursts of activity, or sprints.

These principles were built into 12 points that bear quite a striking resemblance to Toyota's:

1. Achieve customer satisfaction by early and continuous delivery of valuable working software.
2. Welcome changing requirements, even in late development.
3. Working software is delivered frequently (weeks rather than months).
4. Close, daily cooperation occurs between business people and developers.
5. Projects are built around motivated individuals, who should be trusted.
6. Face‐to‐face conversation is the best form of communication (co‐location).
7. Working software is the primary measure of progress.
8. Sustainable development is able to maintain a constant pace.
9. There is continuous attention to technical excellence and good design.
10. Simplicity – the art of maximising the amount of work not done – is essential.
11. Best architectures, requirements, and designs emerge from self‐organising teams.
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.

There is some debate about where this approach can or should be applied. It is clearly more suited to relatively small‐scale, early‐stage activities with open objectives rather than large‐scale, closely defined projects in heavily regulated industries such as pharmaceuticals, nuclear, and aerospace. However, many interesting elements of the approach can be used in a wide range of situations.

The terms scrums and sprints are used extensively in this field, echoing, perhaps unknowingly, a 1986 paper (Ref. 6) by Hirotaka Takeuchi and Ikujiro Nonaka in which they drew an analogy between successful product development systems and the game of rugby. The two authors pointed out that rugby games, as with any team sport, operate to only the most general of plans and that results are obtained by passing the ball repeatedly between players as they move forward together down the field of play. As a gross simplification, and with apologies to rugby aficionados, the game alternates between scrums and sprints. Takeuchi and Nonaka found similarities between rugby and the successful product development companies that they had studied in fields such as automotive, copiers, cameras, and personal computers.

Organisations seeking to improve their product development performance can benefit by studying agile software methods. Areas for potential learning could include team structure and dynamics, planning approaches, customer engagement, and a results orientation. Given that most engineering products are now a mixture of software and hardware, the agile approach will cease to be just the preserve of the software industry.

13.14 Concluding Points

As noted above, an effective approach to developing technology and products is a powerful competitive weapon for an engineering organisation. This book has provided an overall framework for such an approach. New and developing organisations can use the material to guide their way forward. Existing organisations may have to change what they already have.

Change within organisations is a well‐researched topic but is not easy to achieve. There are structured ways of bringing about change that have been shown to work and to be capable of achieving permanent results. They can, however, seem laborious, with much emphasis on vision, leadership, creating urgency, and communication, rather than the actual improvement activities themselves. This thorough approach has been shown to be necessary to overcome the invisible blockages that change entails.

This is particularly the case with technology and product‐creating activities that do not exist in isolation but that involve most areas of companies in this field. A persistent and determined approach, coupled with a good understanding of human psychology, are therefore needed to achieve permanent results.

References

Kotter's book is something of a classic in the field of change management. It is derived mainly from studies of major corporations and their problems of general management. However, the lessons have much wider application.

1. 1 Kotter, J.P. (2012). Leading Change. Cambridge, MA: Harvard Business Review Press.

Philip Crosby's book is also a classic in the field of quality management.

1. 2 Crosby, P.B. (1979). Quality Is Free, the Art of Making Quality Certain. New York: McGraw‐Hill.

The full text of the interview with Gary Hamel can be found here:

1. 3 Jackson, T. (1997). The Management Interview. The Financial Times (24 April).

The Toyota product development system is comprehensively described in:

1. 4 Morgan, J.M. and Liker, J.K. (2006). The Toyota Product Development System: Integrating People, Process and Technology. New York: Productivity Press.

This is a short document that overturned the approach to software development:

1. 5 Highsmith, J. Beck, K., and Beedle, M. et al. (2001) Manifesto for Agile Software Development http://agilemanifesto.org

The roots of agile methods go back to:

1. 6 Takeuchi, H. and Nonaka, I. (1986). The new product development game. Harvard Business Review .