Key Issues in New Product Development ...

Key Issues in New Product Development Controllability Improvement — Lessons Learned from European High-Tech Industries Kristian Rautiainen1, Casper Lassenius1, Jukka Nihtilä2 and Reijo Sulonen1 1

Helsinki University of Technology, P.O. Box 9555, FIN-02015 HUT, Finland 2 Theseus Institute, B.P.169, 06903 Sophia Antipolis, France

Abstract— An interview study reveals the problems companies face trying to improve the controllability of their new product development (NPD). The primary improvement area at the moment is the front end of the NPD process. Other improvement areas include the visibility and tracking of projects, and communication between people and projects.

I.

INTRODUCTION

Sustainable improvement of any process requires controllability [7]. Controllability can be understood as an attribute of an entity that states to which degree the entity can be controlled. Or put more simply, controllability is the degree to which you can steer an object of control — e.g. a product development project — towards a predefined goal. In the late 1980’s many companies perceived that the leverage of improving manufacturing processes was quickly diminishing and initiated programs which would help them to better understand what is going on in the black box called new product development (NPD). Simultaneously, in order to meet the increasing demand for shorter product development cycles, several companies started to organize their product development according to a concurrent model [17]. The traditionally sequential project phases were now executed in parallel. This again necessitated an explicit definition of the role of the different business functions across the project life cycle. For this purpose, several companies adopted a process similar to the stage-gate™ model (Fig. 1). More recently, Initial screen

Ideation

Post implementation review

Gate 1

research has started to identify some of the ingredients of a high quality new product process. Studies indicate that many companies easily spell out their product development process in too much detail [4], [10]. This increases the bureaucracy of the process and is likely to result in a number of workarounds to circumvent the process in order to get the product out of the door. Loch and Kayser found that the main drawbacks of a formally defined product development process were age (“outdatedness”), inflexibility and high process effort [15]. Sobeck et al. studied the product development process at Toyota [18]. They concluded that the bureaucracy of processes is kept to a minimum by describing them with a series of milestones and checklists. The significance of these checklists is that they are not static, but living documents updated after every program. With the high product development frequency at Toyota this means that the checklists are revisited every couple of months. Additionally, the process is maintained by the people who actually use it, not by a staff function that might be tempted to standardize for the sake of standardization. According to the logic of quality management, measurement improves the controllability of the process by providing data for the feed forward and feedback decision making. Recently, both academics and practitioners have started to address the issue of measuring product development. The measurement systems developed by prior research can be grouped into two broad categories. Decision on business case

Second screen Stage 1 Preliminary investigation

Stage 5 Full production & market launch

Gate 5

Gate 2

Stage 4 Testing and validation

Precommercialization business analysis

Fig. 1. The Stage-gate ™ process model [5].

Stage 2 Detailed investigation (business case)

Gate 4

Postdevelopment review

Gate 3

Stage 3 Development

The first — tactical systems — satisfy the information needs of a project manager and an empowered team [3]. The second — strategic systems — satisfy the information needs of process owners or general management [1], [9]. The Purpose of the Paper Prior work has identified the characteristics of a “good” product development process and a set of measures both for monitoring the progress of an individual project as well as assessing the performance of the overall product development process. The underlying principles of defining the product development process seem to be intuitively correct and the stage-gate model is today apparently widely accepted. However, the controllability of NPD is still typically bad. Most projects exceed the planned budget, schedule or scope. The practical issues of project management and the controllability of NPD merit a further field investigation. The purpose of this paper is to report on the interview study we conducted, and to present some of the lessons that some of the leading European companies have learned when trying to improve the controllability of their product development. More specifically, we tried to get tentative answers to the following questions: • • •

What are the main issues in NPD controllability? What kind of control mechanisms and metrics do European high-tech companies use in their NPD? What are the main problems on different organizational levels?

The rest of the article is structured as follows. First, we describe the analytical framework, which we have developed partly based on early findings in the study. Second, we give an overview of the research methodology and the case-study companies. Third, the findings are summarized and discussed. The article is concluded with a recapitulation of the principal issues to be addressed by future research.

The focus of the paper

Aspect Level

Objects

II. CONCEPTUAL FRAMEWORK An analytical framework for controllability improvement (Fig. 2) has been developed in an ongoing research project, of which this interview study is a part. The framework expresses controllability in terms of four organizational levels and four controllability aspects. At each level, the same aspects are considered: objects of control, goals, metrics, and control mechanisms. The aspects at different levels should be interrelated: the corporate strategy should be communicated from the strategic level, through the process and project levels, down to the individual level. The objects of control identify what we are controlling; they should be organizationally identifiable entities. Examples of objects of control include “business unit X” at the strategic level, “product development process A” at the process level, “product development project Z” at the project level, and “developer Z” at the individual level. For each object of control, quantitatively or qualitatively measurable goals should be set. These goals tell us where to steer the object of control. For each goal, metrics are derived, which provide us with data for decision-making and control. Also, control mechanisms should be identified related to each goal. The control mechanisms identify by which means and actions we intend to reach the goals. Examples of control mechanisms include product roadmaps, process models, training, schedules, and budgets. The matrix representation of the framework simplifies the picture: all relationships are not depicted. E.g., the links between mechanisms and goals have been left out for reasons of clarity. The framework takes a broad view of control: it is understood as “any kind of goal-directed influence” [12], and combines the structural, or measurement, and the behavioral approaches to control [2]. The structural approach can be seen through the use of goals and metrics. From the behavioral approach, we have adopted the notion of control mechanisms, i.e. mechanisms that you use in order to make people work towards the goals of the organization. The framework has been described in more detail in [14].

Goals

Metrics

Strategic Process Project Individual

Fig. 2. The Controllability Framework.

Mechanisms

TABLE I SAMPLE DESCRIPTIONS BU

Main BU business

Research site

# of respondents

A

Wireless communication products

Finland

B

Products for anesthesia and critical care processes

Finland

4

C

SW and HW for the switching platform of both mobile and fixed networks

Finland

5

D

SW for fixed network switching systems

Finland

4

code 5

E

Optical sensors for meteorological applications

Finland

4

F

Components for wireless transmission

Finland

4

G

SW for mobile network switching systems

Finland

5

H

Magnetic ballast for the lighting industry

Finland

3

I

Travel reservation systems

France

5

J

Wireless communication products

France

6

K

Communication controllers and hubs

France

4

L

Network management systems

France

5

The framework ties together strategic and operations management, and builds upon the ideas of communicating corporate strategy through measurable goals, e.g. [11], [16].

III. RESEARCH DESIGN AND METHODOLOGY During the winter and spring of 1998, we interviewed 54 persons involved in NPD at 12 business units of 10 companies. The overall goal of the interviews was to obtain a better understanding of how companies manage and control their NPD. We approached all in all 13 companies regarding the study, but 3 declined politely. The sample selection was based on the companies’ business performance, market position, and their focus on innovation and NPD. As Table I shows, 8 of the interview sites were located in Finland and 4 in France. The size of the NPD organizations in the sample business units ranged from a few people to several hundreds. The size of the NPD programs undertaken by the organizations ranged from a few man-months to a hundred man-years. The number of concurrent NPD subprojects ranged from a few to a couple of hundred. A. Data Collection and Analysis The data was collected via interviews. To get a broader view of the management and control practices employed in NPD, we interviewed people at different levels in the NPD organization: the strategic level, the process level, and the project level. The interviews were semi-structured, following

the same discussion outline, which is described in Appendix A. The aim was to seek responses to a set of themes, the focus of which varied, depending on the level. On the strategic level the aim was to obtain an overall picture about the role of NPD in the business unit, and how NPD is planned and managed on a long-term basis. The questions on the process level focused on the NPD process and the related measurement system of the unit. Finally, on the project level, the questions focused on the management, control, and progress monitoring of individual projects. On each level, we also asked the respondents to describe the biggest problems they face in their NPD activities, and what they have tried to do about these problems. A write-up of the interviews was written and sent to the respondents for commenting. The analysis of the data followed the qualitative approach illustrated in [6]. The data analysis was based on our framework for the improvement of NPD controllability, as described in the following section. B. Using the Controllability Improvement Framework for Analysis For the purpose of this paper, our analysis focused on improvement issues. We concentrated on the problems faced by companies today, and the ways in which they have tried to overcome these problems. Since most of the interviews were conducted before the framework was finalized, the interviews did not fully comply with the aspects of the framework.

TABLE II MAIN PROBLEM AREAS AND IMPROVEMENT ISSUES BY LEVEL Strategic level

Process level

Project level

Front end

Process improvement

Front end

C,D,G,H,I,J,K

E,F,G,I,J,L

A,B,E,F,G,I

Tracking

Communication and data transfer

Project mgmt and coordination

A,C,D,F

B,C,F,J,L

F,H,I,J,K,L

Competence management

Resource management

Resource management

A,F,K

C,D,F,G

C,D,G,J,L

Change management

Front end

Process improvement

D,F

A,D,G

C,E,F,G

Tracking

Tools for project management

F,G,L

A,D,F

Therefore our analysis concentrated more on the levels of the framework. In order to be able to compare the views of the respondents at different levels, the responses at a certain level were written in the slots of that level, regardless of the content of the response. For example, if an R&D Manager told about how the progress of a project was monitored, the response was placed on the strategic level, not the project level. The responses to the questions about the biggest problems in NPD were also categorized according to the levels of the framework. By using the framework as a tool for analysis, we got valuable insight of the applicability of the framework, which helped us validate and improve it. One manifestation of this was the incorporation of the individual level to the framework, which was a result of findings at an early stage of the research.

IV. FINDINGS In general, we found that almost all of the business units had adopted, or were in the middle of adopting a formal NPD process similar to the stage-gate™ model in Fig. 1. Only one of the business units (H) did not have any formal process defined. This was attributed to the small size of the NPD organization — only a handful of people — and to the fact that almost all development was increments made to already existing products. The spirit in the business units was very positive. Many respondents made a specific point of how much all the people wanted to improve their work. Table II summarizes the main problem areas and improvement issues sorted by level. The primary issue in companies at the moment seems to be the improvement of the front end, i.e. the early phases of NPD that precede the actual detailed design and development of a new product [13]. In the following sections we will discuss the findings on the different levels in more detail.

A. The Strategic Level Our findings confirm that companies have acknowledged the importance of the front end, but managing the front end is still considered difficult, especially recognizing and understanding customer requirements. Surprisingly some business units also seemed to lack a documented product strategy. In highly innovative businesses — such as telecommunication — the customer does not always know what technology is able to do. When pressure increases for reduced cycle-times, the problem is that the development team will tend to start faster as well, not taking the time to verify that the requirements have been understood properly. However, time is not always the decisive factor. In business units B and E the quality and reliability of the product are much more important than time-to-market. This underlines the importance of a thorough understanding of the key business drivers which shape the competitive reality. Tracking ongoing projects seemed to be problematic to strategic management. Some respondents desired real-time information about the projects and others were struggling with the creation of meaningful, proactive metrics to support them with the management and control of the projects. Competence management is getting a lot of attention. In telecommunications, for instance, the demand for skilled personnel exceeds the supply from schools and universities. Hence planning and securing the recruitment of skilled personnel is a competitive factor, maybe even a decisive one. The challenge is not an easy one, as a comment illustrates: “I have never seen anything provided (by the line organization) in terms of skills.” Managing change and making decisions was brought up as a key issue by a few of the respondents. One comment from a senior manager describes the feelings: “The effectiveness of a project depends on how fast different decisions can be made. The project organization should always have back-up plans, in case of surprises.” Especially in the case of geographically

dispersed teams the issue of decision making can get complicated. B. The Process Level Process improvement is not surprisingly one of the main issues on the process level. The process models undergo what seems to be constant development and change, trying to keep up with new ways of working and new trends. Unfortunately this leaves gaps, either in the behavior of people or in the process descriptions, which never quite seem to match. One of the respondents considered their process to be passive instead of being a real tool with added value. Another view, claiming that a supporting information system is a major success factor in implementing a process, supported this opinion. A project can be divided into tens of subprojects. Communication and data transfer between these is a key issue according to many of the respondents. Communication gaps may cause unnecessary work and hinder long-range planning and optimization of work. Efficient dependency management — who has to do what — is a critical success factor in the coordination of efforts. An active change management process can also be used as a coordinating tool. “I was promised resources, but when the time came, I had nobody.” was a very usual comment during the interviews, both on the process level and on the project level. Typically this was caused by another project lagging behind in schedule tying up the resources. This was attributed to bad estimation of workloads and lack of tools for resource management. For instance, none of the business units tracked resources over line organization boundaries, which makes resource management on the company level very difficult. “The process of refining product specifications starting from a product roadmap has a huge improvement potential.” was one of the comments concerning the front end. Finding good metrics that correspond to reality was one of the problems in tracking. Developing metrics to measure the performance of the NPD process, was a common improvement issue. C. The Project Level Most projects are launched without a clear, defined target, if one is to believe the responses in the interviews. This is understandable where industries with rapid changes in technology — like the telecommunication industry — are concerned, but also business unit B, with products for the medical industry, reported that the requirements are unclear at the beginning of a project. Making a structured analysis of customer needs and understanding them seems to be a major improvement issue. The subject of estimating workloads was already mentioned in the previous section. In most of the companies estimation is based on prior experience. This experience is seldom documented and analyzed for improvement purposes, but is rather found in people’s minds.

One of the best examples of the accuracy of estimation is the comment “estimated hours are exceeded in every project”. “Project management is hard for your average engineer; they are uncomfortable with the fact that the plans change during the project.” was a profound comment from one of the respondents. It nicely sums up the state of project management in NPD today. A very common mistake is to underestimate the time needed for project management and coordination. In one of the sample companies project managers were usually key resources in the actual development work also, which left them even less time for management. A very good point was spoken out by one of the respondents: “Project management is one competence among others, and mastering it is a critical success factor”. Another business unit reported that the demand for project management training far exceeded the supply. Some of the respondents were also unhappy with the existing tools for project management. Project managers complained that the introduction of new ways of working and new processes to use is done much too frequently. Before people adapt to the new ways, other ways are already being introduced. The demand for freezing the NPD process for longer periods of time was clear among the respondents. This would make it easier to adopt companywide ways of doing things and managing projects. Now all the project managers have different ways to manage their own projects, demanding different ways of doing things — reporting for instance — making it complicated for personnel working in multiple projects to remember how they were supposed to do things in a specific project.

V. CONCLUSIONS Companies view the concept of control narrowly. When respondents were asked about the control mechanisms of the business unit, the answers were something like “we make project plans and compare progress to the plans at regular meetings”. Answers to other questions revealed a multitude of other control mechanisms, like training, bonus systems, and informal discussions. When confronted with the question “do not these control your actions?” the respondents agreed willingly. On the two higher levels there was a need for better visibility and tracking of the projects. Meaningful metrics that help in the control of NPD have been found very hard to develop. Also real-time communication and information transfer between different subprojects was considered an important improvement issue. On the project level this was not seen as a major problem, although project management in itself was considered difficult, a manifestation of which was the lack of time for management in a few companies. However, the respondents named “gathering and supplying information and keeping up communications with other projects” as part of project management. The change request process, which we view as an important part of information sharing and a valuable control mechanism, was in many cases

considered a waste of time at the project level. At least, this is the impression we got from comments like “people should use change notifications more” and “if it does not affect customer requirements, we can just go ahead and do the necessary changes”. While respondents on the strategic level claimed they did not have a good overall picture of the projects, respondents on the project level seemed to lack an understanding of “the big picture”. There seemed to be a lack of direction and vision for the companies, or at least the vision had not been successfully communicated. The project managers told us that not knowing and understanding the customer needs made the designers unsure about what they were designing, especially in situations where they had options about some details in the design. Change notifications were seen as isolated incidents, not as part of the development process. In many of the sample business units there was confusion about the precise roles of the different functions (e.g. marketing, production and functional design) that work with NPD. There was also confusion about the different processes (e.g. the change management process and the quality management process) that are part of the overall NPD process, specifically on the issues of when, how and why they are used, and what is required as input to the processes. This might be the result of insufficient communication and training or failures in the implementation of the processes [8]. Evaluation of the Framework When the interviews were planned, our focus was on the management of NPD projects. We realized that launching projects should be linked to corporate strategy, and that a process was needed to help coordinate and formalize the management of projects. Hence we decided that the framework should have these three levels and that interviews needed to be conducted on each of the levels. The need for an additional level — the individual level — was discovered as a result of early findings in the study. Using the framework as a tool for analysis was a good way of focusing the work. The matrix representation also helped in visualizing the data. One problem, however, was that some of the data had to be forced into the aspect slots of the matrix, which enhanced the researchers’ subjective assessment of the data. The slots of the matrix were used in a different way in the analysis than in the pilot companies that are using the framework to improve the controllability of their NPD. However, the concepts of the framework seem to work as a good basis, both for improvement and analysis. Future Research Issues Our research indicates that the front end is still fuzzy. Further research need to be done both with a holistic approach and with a focus to parts of the front end. Although tools exist for collecting and managing customer needs — e.g. Quality Function Deployment, Conjoint, and Voice of the

Customer — the companies in our research had problems specifying customer requirements. The need for a more transparent view of the NPD process was expressed in our study. More specifically, the visualization of the interdependencies between the different actors in the process was perceived pivotal. Additionally, more effort should also be put to the practical implementation of processes in the organization and to organizational change management. These issues call for more cooperation between the researchers and the companies. Communication and visualization of information, and the development of metrics derived from the strategic and operational needs of companies, are issues we are working on in our ongoing research project on the improvement of controllability of NPD. We will also continue to analyze the data from the interview study trying to find emerging patterns or “controllability scenarios” for different situations companies face. REFERENCES [1]

P. S. Adler, A. Mandelbaum, V. Nguyen, and E. Schwerer, “Getting the most out of your product development process,” Harvard Business Review, vol. 74, no. 2, pp. 134-152, March-April 1996.

[2]

S. L. Ansari, “An integrated approach to control system design,” Accounting, Organizations and Society, vol. 2, no. 2, pp. 101-112, 1977.

[3]

N. Brown, “Industrial-strength management strategies,” IEEE Software, vol. 13, no. 4, pp. 94-103, July 1996.

[4]

R. G. Cooper, “Third-generation new product processes,” Journal of Product Innovation Management, vol. 11, no. 1, pp. 3-14, January 1994.

[5]

———, “Benchmarking new product performance: Results of the best practices study,” European Management Journal, vol. 16, no. 1, pp. 117, 1998.

[6]

K. Eisenhardt, “Building theories from case study research,” Academy of Management Review, vol. 14, no. 4, pp. 532-550, 1989.

[7]

E. Eloranta and J. Räisänen, A Method for the Design of Production Management Systems, in Huebner, H., Paterson, I. (Eds.) Production Management Systems, Strategies and Tools for Design, North Holland, pp. 77-90, 1984.

[8]

M. Forssén-Nyberg and J. Hakamäki, “Development of the production using participative simulation games - two case studies,” International Journal of Production Economics, vol. 56-57, pp. 169-178, 1998.

[9]

C. H. House and R. L. Price, “The Return Map: Tracking product development teams,” Harvard Business Review, vol. 69, no. 1, pp. 9299, January-February 1991.

[10] R. R. Kamath and J. K. Liker, “A second look at Japanese product development,” Harvard Business Review, vol. 72, no. 6, pp. 154-170, November-December 1994.

[11] R. S. Kaplan and D. P. Norton, “Using the balanced scorecard as a strategic management system,” Harvard Business Review, vol. 74, no. 1, pp. 75-85, January-February 1996. [12] I. C. Kerssens-van Drongelen and A. Cook, “Design principles for the development of measurement systems for research and development processes,” R&D Management, vol. 27, no. 4, pp. 345-357, 1997. [13] A. Khurana and S. R. Rosenthal, “Towards holistic ‘front ends’ in new product development,” Journal of Product Innovation Management, vol. 15, no. 1, pp. 57-74, January 1998. [14] C. Lassenius, M. Nissinen, K. Rautiainen, and R. Sulonen, “The Interactive Goal Panel: A methodology for aligning R&D activities with corporate strategy,” in the proceedings of the 1998 IEEE EMS International Engineering Management Conference, May 3-5, 1999, in press. [15] G. H. Loch and H. J. Kayser, On the Company-specific Nature of Project Success Drivers in Product Development: An Empirical Study of a European Technology Manufacturer. INSEAD Working Papers 98/21/TM, INSEAD Fountainebleau, France, 1998. [16] R. L. Lynch and K. F. Cross, Measure Up! Blackwell Publishers Inc., Massachusetts, USA, 1993. [17] I. Nonaka and H. Takeuchi, “The new new product development game,” Harvard Business Review, vol. 64, no. 1, pp. 137-146, January-February 1986. [18] D. K. Soebeck II, J. K. Liker, and A. C. Ward, “Another look at how Toyota integrates product development,” Harvard Business Review, vol. 76, no. 4, pp. 36-49, July-August 1998.

APPENDIX A: THE DISCUSSION OUTLINE FOR THE INTERVIEWS The interviews were semi-structured, following a predefined discussion outline consisting of a set of themes. In each business unit, the same themes were discussed. The themes for the strategic level were: Strategies • business strategy • product strategies • technology strategies • competence management • resource allocation Processes • the product processes • the product development processes • the change management processes • process metrics Projects • pre-project activities • project planning • organizing the projects

• • •

project classification control mechanisms project metrics and follow-up

Industry background • the size and structure of the organization • the products • the customers • the competition The themes for the process level were: Process models • the structure and contents of the models • project-specific tailoring of the models • documentation • training • process improvement Multi-project environment • the organization of projects • the distribution of responsibilities • resource allocation • the project load • change management • control mechanisms • documentation Process metrics • collection of data • analysis of data • reporting • visibility of metrics The themes for the project level were: Project planning • pre-planning activities • project planning activities • the contents of a project plan Project organization • program division into projects • project division into subprojects • the project environment • project support Project management • control mechanisms • day-to-day management • change management • risk management

Project metrics • collection of data • analysis of data • reporting • visibility of metrics Learning • project post-mortem • collecting and utilizing history data