This book is about managing new product development using project management concepts and tools. The author has been guided by seven key principles in addressing how to manage new product development projects. These principles are addressed here briefly and then wrapped up again in Chapter 10. These principles are as follows:

Principle #1. Develop project management and new product development processes, and integrate the two. The theme of the book is that new product development is a largely technical and developmental process that must be carefully managed to control time, resources, and quality. The fundamental contribution of project management tools and techniques is to enable project managers to make the business case for a new product. Both the project management process and the new product development process must be defined in order for this integration to work.

Principle #2. Open the company to new ideas and new partners. The organization has to be open to new concepts and ideas, and sometimes has to take a proactive approach to find new ideas and partners on a global scale. New product development is no longer an "internal" process.

Principle #3. Define measures for choosing new product projects. The development of a new product portfolio requires analysis and evaluation using at least three measures: financial performance for the business, alignment with business planning and strategy, and identification of risks and contingencies.

Principle #4. Create a way through project reviews to stop bad products. New products have a way of moving through the system despite overwhelming evidence of potential failure in the marketplace. One of the key project concepts we explore is the project review, which enables management to make go or no-go decisions at each product development phase.

Principle #5. Choose project managers who understand technology. Project managers must be trained and developed to manage time, resources, and quality, but they also must have a working knowledge of the technology inherent in any new product development. Project management is more than an administrative function; it implies technical judgments as well.

Principle #6. Build cross-functional teamwork and accountability. The new product team is important. If the team is narrowly structured to reflect only

Copyright © 2008 by The McGraw-Hill Companies, Inc. Click here for terms of use.

design and development issues, and not production, marketing, and sales concerns, the team is likely to produce prototypes that work, but that cannot be produced and marketed at a profit.

Principle #7. Ad hoc it when necessary to succeed. Sometimes you simply dispose of process and procedure and jump into the market with a new product because you have to. Success is often achieved in the field through trial and error and pure determination.

The essence of these principles can be wrapped up in single sentence:

Create a loose-tight process that loosens up the company and opens it to new ideas and concepts, but once you decide to go with a new product and fund and develop it, manage and control the process using disciplined process definitions and proven project management tools.

The reader will be introduced in this book reflecting a series of processes and phases, some of them technical and others simply common sense, for managing new product development. Some of these processes, may not provide the kind of detail an engineer might be looking for. The author preferred to stay on the high ground in these discussions and let the reader fill in the gaps with technical details tailored to specific organizations. For instance, we do not go into detail on various configuration management packages available to preserve the structure and components of new products in development, depending on the reader to pursue that level of inquiry.

In some cases we provide perhaps more detail and structure than the typical reader will want. For instance, we provide many illustrations of a key project planning tool, the Gantt chart, with detailed tasks, linkages, and assigned resources. Some readers may be bored by this focus on administrative tools, but our purpose here is to offset the common bias against this kind of tool among new product and marketing professionals.

The author is a student of organizational behavior and leadership, as many of our readers will be. We mention this because we try to place new product development and project management in the context of a company culture. Culture sets the boundaries for management and employee behavior, sometimes unconsciously, and thus deserves some attention. What Pepsi Cola does with a given project in its new product development process may not align with what Coca Cola would do with the same project. Thus "one size fits all" does not work very well when applying standard models of work to new product development. The reader is advised to grasp the conceptual material here and to then work to integrate the concepts into the target organization, whether it be a given company or a case study for training or education purposes.

The reader will also see a bias in the book toward application of management and administrative tools that might be inconsistent with the thinking and instincts of marketing and sales professionals. We see in marketing and sales circles an increasing tendency to depend on product branding and pricing to sell products in the marketplace. With this focus comes an underestimation of the design and development challenges in getting today's new products to market tomorrow. This is why we spend some time on cross-functional teams that reflect both the early product development and later marketing phases in their composition. The truth lies somewhere in the middle of this wide-ranging spectrum of activity, but the smart program manager accountable for the whole process will build those interests into the team early in the process.

The reader will also see in this book considerable ambivalence in applying some of the newer project management tools that focus on the big picture and leave the details to team members. For instance, the so-called critical chain concept aims for single bottlenecks and advocates the phasing of projects into the pipeline one at a time instead of multi-tasking the workforce. The results are not in yet on whether critical chain theory really works.

Another debate in project management circles has to do with the strategic value of projects, for example, project portfolio management. New thought about the strategic application of projects focuses more on alignment of projects and project selection. This focus on project selection means that projects need to be planned early and fleshed out in order to decide whether to undertake them in the first place.

The author sees both sides of these kinds of healthy indicators of change in the project management field and tries to portray those sides in the discussions when possible.

This book is different in many ways from past treatments of new product development and project management. This is a managerial view of the new product development process, the perspective of company management in the new product business. The view is driven by the need to grow the business, control resources and time to market, monitoring how the process is going against business strategy, and when to proceed and when to "pull the plug" on a bad product. The book takes an integrative perspective on the process, not bound by narrow views of consumer products or services or traditional marketing concepts that sell whatever product is produced. Emphasis is given to what can and does go wrong with many new product development and marketing initiatives because things weren't planned very well.

While the book provides a reasonably detailed discussion of new product development from a technical view, its purpose is to put that process in a management framework, to embody technical process in managerial context. New products are not projects until they evaluated, planned, scoped-out, scheduled, budgeted, managed, and monitored by managers. It is not technical process failure that inhibits the successful introduction of new products into the economy—it is typically managerial and marketing failure.

A short journey through the history of these two fields—product development and project management—may be helpful here.

What is new product development? There is a presumption in many quarters that new product development refers essentially to consumer products—not system or process products. That is, the concept of product is confined in this marketing sense to products for consumption, and marketing is the process of ensuring that customers are attracted to and buy the product. However, the other view is that new products can be system or process products as well, that the development of new ideas and concepts for new products as a part of a system, e.g., an electronic instrument for a business aircraft that will enhance pilot performance, or a new service concept that provides a new broadband platform for public safety communication, are new "products/ processes/services."

So it turns out that the field of new product development has been driven largely by marketing and market launch views of the world, and more recently by a focus on the new product stage-gate process articulated by Robert Cooper. In the current literature, the process is seen as a logical sequence of generating new products, making the business case, testing and prototyping, marketing, "launching," and distributing the new product. New product activity is often viewed as "separate" from the rest of the company's product design and production processes, somehow placed in a distinct category and treated as such. This reflects the propensity of new product developers to think of themselves as "non-operational" and non-routine in their perspective. The process is rarely seen from a managerial view, e.g., what does the process cost, how long does it take, who is doing the work and how well are they doing, when should we stop it, and will it help the business grow.

On the other hand, the field of project management has been driven by narrow views of a project as a schedule and a budget. More recently we see a focus on portfolio management and how projects are selected and critical chain management focusing on resource bottlenecks and shortening task durations. Project management has been articulated traditionally as a set of planning and controlling tools to get products done on time and on budget. Only recently has the field begun to look at the broader perspective on projects, e.g., that projects are rarely managed as distinct pieces of work, that projects are all creative and innovative because of the changes that take place during their life cycle, that it doesn't matter that a project is on time and within budget if it does not hold promise to grow the business, and that all product development efforts must be customer-driven. A relatively new concept, critical chain theory, now has nudged the field to look at its own propensity for micro managing schedules, and changes the focus to bottlenecks, slimmed down task estimates, and monitoring the big picture. But still, project management and administrative concerns are seen by many professional engineers and marketing people in new product development as not worth their time.

I see these historic and narrow conceptual boundaries in these two fields as inhibitors of imagination and understanding, as evidences of Thomas Kuhn's (The Structure of Scientific Revolution) paradigms that restrict a full view of what is really happening out there and what should happen out there. Paradigmatic change occurs only when someone can overcome the blinders of constrained thought processes to question conventional wisdom and to get at reality for those in a real work setting and who muddle through the messy world of the competitive global marketplace.

to explain why things go "south" in a complex endeavor or new product project in systematic terms, and as if the world of human systems operated in a predictable and controllable way. We seek answers for all failures to fix them, yet we often do not know what factors were important. We assume that a system is in place and if the system fails we want to find out why it failed. When a business or new product project fails, we conclude that "somehow this failure could have been avoided if we had just studied and analyzed the risks a bit more, perhaps drilled a little deeper into the inherent impacts and probabilities."

Such an approach assumes that risks and failures operate in a predictable way; that the factors that lead to risk events and failure can always be identified, catalogued, and controlled; and that more analysis will uncover the secret to the mystery. The principle is that we should be able to identify what might happen, what the probabilities are, what the impacts are, and how to respond. It assumes we can find attribution, that we can attribute failure to key events or circumstances. It is true that the root causes of new product project failure are rarely a mystery—they often have to do with business performance, market conditions, leadership bias, and lack of support. They rarely have to do with technological failure—the engineers will usually find a way—it's the organization that cannot produce success.

The problem is complicated by the variety of definitions among stakeholders of failure and success. One person's failure is another person's success. A project that overcomes technology risk can deliver within budget and schedule and be termed a success by the project team, but it is possible that this same deliverable cannot be manufactured, or that the customer is not happy with the outcome, or that the business itself fails for reasons that have nothing to do with the project.

The drive to mystify risk assumes that there is always one true risk involved in every factor, task, or project, and that to solve the risk mystery we have to go to extreme limits to identify and quantify that risk. This makes the subject more complicated than it needs to be—and assumes that it is within our grasp to capture all the root causes of risk. Somehow, if we can establish that the risk of failure of a team task to integrate an information system is 66 percent rather than 24 percent, we make decisions based on an unreal confidence in science to predict things like the economy.

What is missing here is the fact that businesses and projects are human, not mechanical systems. Despite our increasing propensity to consider the study of organizational and new product development efforts in business to be a science rather than an art, human behavior is often unpredictable and counterintuitive. Despite our understanding of complex systems, we cannot identify all of the factors that contribute to risk and success even if we all agree on the definitions of those terms.

In addition, technical professionals and engineers—especially those in new product ventures—have developed their own language and values, which sometimes complement but often conflict with good project risk management. Theirs is a focus on the product and sales, not on business alignment, growth, and financial performance. The people and communication issues in engineering and product development are not unique, but they are accentuated by a working "axiom" of

The fact is that most management thought suffers from the lack of a "full and realistic screen." My experience is that success in business is a function of a wide variety of factors unrelated to project management, some driven by outside economic and social factors and forces which create the conditions for business growth. This is not to say that leaders and managers cannot steer companies in the right direction, given their reading of the outside world and their own organization's capacity, or that the generation of new ideas and new products cannot influence the market and create business growth and profitability if they are properly nurtured, managed and delivered. But there is no substitute for planning. We often see that our luck seems to get better with good project planning.

This practical view guides my treatment of this important subject and helps me view new product development with new eyes, with more focus on what actually happens when business succeeds or fails in this process of innovation and performance, and how managers actually manage under the daily stress of the new product work setting in the real world—where many factors are actually unmanageable.

I am driven by the need to see things as they are instead of how they should be. Then when I see those things clearly, I begin to see how they could be. It is the backward mapping process that starts with what happened and then backs up to how it happened and how it might have happened differently or "better."

To illustrate my point, let's take my friend the engineer. We'll call him Bill Close. Bill is an electrical engineer in an electronic instrumentation company producing avionics products. Bill is a functional manager, not a project manager; he manages electrical engineers who serve on projects to produce new avionics instruments for mid-sized aircraft. He could very well be an engineer for a toy manufacturer or a home improvement tool producer.

Bill works in an environment in which the production of new equipment is driven by factors largely out of his control. Ideas for new products come from management, customers, company ownership, competitors, and suppliers. New ways of meeting future customer needs coagulate on the fringe, during the production, distribution, and consumption of conventional products, not from starry-eyed engineers who see visions of new products in their sleep. New innovations are embedded in the current process of a company, not in some collection of autonomous, and off-center, "integrated ideation and product teams." Without grounding, new products do not survive.

Bill's people are managed to a certain extent in a typical new product environment by project managers who share responsibility with him for the performance of the product. He can be very skeptical of a new product process run by a project manager whose major focus is on time and budget and not on the performance and quality of the product. And marketing people continue to press for getting the product out before it is ready. To Bill, these company forces threaten good engineering.

Further, it is my observation from years of watching and working with companies and public agencies, that new products and services induce rather than follow customer need. "Needs" are not discovered; they are created and induce economic demand in the marketplace because they create value as incremental improvements in the current material and service world. Therefore, managing new products and services is most effective when positioned on the edge of the market, on the incremental periphery of the way people and companies live and breath each day. Evolutionary change prevails in the process of successful new product development because fundamental change does not occur in major breakthrough steps as much as in controlled evolution of ideas and collaboration. We saw in Universal Avionics, Inc. that aviation instrumentation and systems improvements were not invented over night, but came from many years of trial and error, incrementally. And leaders do not generate change in their companies over night simply because of their charm and charismatic disposition. This uniquely American view of invention and innovation suffers from the general naivete of our Hollywood view of how "great" things happen and how leaders lead. It is typically professional people working each day together who create market and business value in new products to serve customers.

My point with my friend Bill is that he is not a project manager and does not belong to any project team, but he is vital to the success of any product development effort in his company because his responsibility is technical and engineering process, quality, professional development of his staff, and keeping his eyes on technical quality. He casts an uneasy eye on managerial decisions that short cut good engineering.

In today's global economy, businesses are increasingly challenged to generate and translate new, innovative ideas into new products and services, and then to get those products and services to market—cheaper, better, and faster. At the same time, project and product managers face the difficulty of stopping bad ideas at critical points or "gateways" in the process before they become expensive project and product—and company—failures. These "go and no-go" decision points occur in what is termed project review stage.

This book will integrate the two fields—new product development and project management—into one practical treatment of how to drive new concepts and products to market faster, better, and cheaper. The basic issue is how to move new products and services quickly from concept to product to market as a managed and seamless process, free of technical and handoff bottlenecks, technical problems, and delays, and how to ensure that bad products are stopped at key review points, before they become product and project failures.

New product development, as defined and supported by the Product Development Management Association (PDMA), centers on customers, product designs, marketing, launch plans, and the business case for a product. The PDMA community is dominated by marketing people and marketing ideas, not project management ideas. However, PDMA-oriented guidance is beginning to reflect the managerial and organizational issues in producing successful new products.

On the other hand, resources, schedules, Gantt charts, budgets and costs, and teams drive the project management field. PMI (Project Management Institute)-oriented books typically address the managerial and resource issues in producing deliverables in an organizational environment. Project management and the traditional PMI process and certification process focuse on resources, scopes of work, contracts and proposals, schedules, budgets, and teams, providing the essential administrative, organizational, and managerial framework for designing and producing a deliverable. But classic project management does not push the frontier of new product development or marketing. Project management has a process and managerial focus.

Many good authors have addressed product development. Robert Cooper in Winning at New Products and Portfolio Management for New Products, Michael McGrath in Next Generation Product Development, and Bean and Radford in The Business of Innovation are good examples of excellent references. But there is little out there on managing new product development. See our bibliography for other good sources, especially on new product development from a marketing aspect.

Classic project management texts address the PMI PMBOK process but rarely get into hard product development and engineering cases; Kerzner, Lewis, Larson, and others have produced books and texts in project management, and some include good case studies. But project management books rarely see new product development as the key, generic process structure for the deliverable.

A common process for both fields is portfolio development, but new product people see this as a business case and marketing process, where project managers tend to think in terms of feasibility, financial performance, strategic alignment, and the right number of projects in the pipeline.

The managerial implications of new product development come especially to light when considered in the context of multiple projects and resource management challenges. How does a program (multiproject) manager keep track of several new product projects in a portfolio and ensure a good balance and mix, consistent management, and good decisions on progressing from one phase to another?

Internet Impact on New Product Development

The Internet is changing the new product development process such as Internet sources as through Wikipedia, YouTube, and Innocentive. Models, simulations, and basic performance information on new products are now instantaneously available through the Internet, freeing new product developers to generate new ideas and demand for new information instead of simply researching for current product information. Virtual teams now dominate the process. This means that innovation and creativity will be increasingly focused on truly incremental product and service concepts, not reinventing the wheel. Engineers can find out easily what now works, what is in the pipeline for development, and what is fair game for new development. Customers and client groups now can participate in new product development through Internet market research and direct involvement, thus the design and testing process cannot be seen as more concurrent and integrative, and less sequential.

Risk and New Product Development

As evidenced in Figure I-1, there is a change going on in new product development process. This change indicates movement from pure marketing to control of resources and time, to integration of new product development into the mainstream of company activities, to move emphasis on go or no-go decisions, and to ensuring that new product managers have adequate technical background. These changes portend general transaction to a more controlled, managed process.

Business risk is embedded in managing new product development, from beginning to end. To a very real extent, new product development is business risk management, the design and testing of a company product and/or service that carries with it risks, opportunities, and contingencies. Project risk management is an art, not a science. I have always been skeptical of scientific and overly quantitative answers to complex social, organizational, and project outcomes, especially when products, customers, products, and markets are involved. I think risk can be stewarded and managed by good planning and analysis, but in the end it is often the gut feel of a project manager that turns a project in the right direction and overcomes risk.

We tend to look for ways to control business and new product outcomes that sometimes simply cannot be controlled. It is as if there is some underlying need

New Product Development Today: Separate Processes

Managed New Product Development Tomorrow: Integration

Setting Up

How to Address New Products

Focus on Marketing

Treat New Products as Separate

Focus on Process or Control

Focus on Process and Technical Data

Corrective Action

Expect Technical and Professional People to Control Time and Cost and Correct Mistakes

Focus on Resources, Time, Quality, and Control

Treat New Products Strategically as Part of Company Business Development

Focus on Go and No-Go Decisions and Time to Market

Expect Technical People to be Technical and Project Management People to Manage, Control, and Correct

Post Mortem No Lessons Learned

Figure I-1 Changes in new product developments.

No Lessons Learned

Lessons Learned by Team engineering project management—engineers communicate through channels and thought processes sometimes at odds with cheaper, faster, better. But they are inherently good risk managers. Engineers and technicians are often conflicted in a project management setting by time, cost, and organizational constraints that require they take short cuts to good engineering and risk management. They are challenged by risk and typically want to get it right, rather than getting it on time and at lowest cost. For instance, the measure of "mean time between failures" (MTBF) is often applied to new products, e.g., electronic and technical equipment, and tests are designed to ensure that products perform under stress at the intended MTBF. MTBF is a risk indicator; the risk of failure is quantified by repeated tests and documentation, thus a quantitative probability can be applied to its future performance. But in most circumstances MTBF is not applicable or suitable because user settings and environments cannot be controlled to really predict all the circumstances a product will experience. And the customer may not be interested—or will not pay for—a certain level of MTBF. But engineers typically would like to get MTBF down to zero if they can—an application of Six Sigma thinking—even at the cost of on-time delivery and budget.

Another complication in project risk management is the resistance to change in the project management or supplier team, as well as in the customer's organization. Typically a complex project and its outcomes trigger the need for organizational change, thus surfacing the resistance of those who do not see the value of change. For instance, a new electronic product produced through a product development project can alter the priorities of the customer's organization as the new product is phased into marketing and sales. The priority on this new product can upset an ongoing dynamic in the organization long supported by the old, replaced product. The risk here is that employees will resist change and undermine new product delivery unless the following factors are in place:

1. Top management support

2. Clear vision

3. Incentives to accept change

4. Incentives to take risks

5. Clear communication

6. Walk the walk, the day-to-day process through which management produces on its promises

I am optimistic that there are useful tools to manage new product risk, and that these tools lie in core business and project planning and management processes. I believe that project risk can be stewarded, but not always controlled through good planning and scheduling—and critical thinking. Through the application of risk management tools outlined and illustrated in this book as

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment