1998-99 New Product Development Quick Tips

 

Should engineers be spending their precious time visiting customers?

A few years ago, managers were concerned about having their design engineers visiting customers. They feared that either the engineers would be too honest, ruining a sale, or they would over-generalize from the few visits they were able to make. Nowadays, these concerns have abated, so the remaining concern is simply: Can I afford to pull a busy engineer off design work to visit a customer?

In fact, your design engineers are your front-line troops, making the countless daily decisions that will accumulate to determine whether or not your product is customer-friendly. Without having "walked in the customers' shoes," these decisions are likely to be made both poorly and slowly.

Consider an airline, where the flight captain is making these front-line decisions. Most captains, who are isolated from their customers by a bulkhead, will announce at the beginning of a flight when it will touch down. But customers don't care about touchdown; they only care about when the plane gets to the gate so they can leave. The captains who pay more attention to what their navigation computers are telling them than about the customers behind the bulkhead will announce the impertinent information every time.

Even a company as admired as Hewlett-Packard and a product line as successful as their DeskJet printers has had problems with unfriendly products. HP has implemented a program of customer visits, including training for their engineers, to make their DeskJets more customer-friendly.

Remember that there are two keys to effective customer contact:
    - Design engineers must be in DIRECT contact with customers.
    - This contact must occur before they start designing.

Quick Tip list  |  Product development publications  |  Home

 

What is the essence of managing risk in a development project?

There are two critical factors to keep in mind in managing risk:
    - Risk must be managed proactively.
    - Risk management must extend outside of engineering.

Proactive risk management is especially crucial when time to market is important. By starting early and addressing risk in an ongoing manner, you basically push the surprises earlier in the project, where they are less damaging to the schedule. Earlier awareness of risk issues provides you with more time to deal with them, which is essential as you shrink your schedules. Finally, because risk remedies get scarcer and more expensive as you get locked into prior project decisions, early risk resolution provides a richer, cheaper set of solutions.

Risk management is normally thought of as a technical issue. Engineers have many tools for dealing with risk. Unfortunately, this is the least lucrative place to look for risks. Numerous studies of product development failures show that most of these failures stem from market and business risks, not technical ones. When we assign risk management to the engineers, we are ignoring the majority of the issue.

In keeping with the proactive and cross-functional nature of risk, there are many ways of identifying and tracking project risks. Some examples appear in a recent article, "Managing Risk As Product Development Schedules Shrink."

When project risk is treated proactively and cross-functionally, it becomes a central means of managing the whole project. It naturally becomes the basis of phase review discussions, and it takes on a project role no less than the project's budget or schedule.

Quick Tip list  |  Product development publications  |  Home

 

How much does it cost to speed up product development?

Many companies have spent a great deal of money to achieve rapid product development without seeing much benefit. It isn't difficult to spend millions of dollars on CAD (computer-aided design) systems, development workstations, or rapid prototyping systems.

Interestingly, these firms have paid the price of admission, but the ongoing "dues" to really see improvement are quite cheap in financial terms. Sophisticated CAD and computer systems are often the price required to even play the game today, but since your competitors can buy these too, they aren't enough.

The firms that I have seen really compress their time to market also invest in management tools that act to reinforce these technology tools.

What are some of these management tools? Early, ongoing customer involvement is one. Dedicated, co-located development teams is another. Still another is a product architecture that supports component and design reuse. MBWA (management by walking around) is a perfect example of one that costs nothing financially but eludes many companies. This one is a speed enhancer because it gives management fresher, more accurate information for taking action quickly than do monthly or quarterly management reviews.

As you might now suspect, these management tools have their price too. It is often paid more in organizational or behavioral change than in financial terms. For instance, co-location or MBWA are powerful accelerators, but they require individuals to change how they operate.

For more on getting benefit from what you put into improving your product development, refer to the article, "Reaping Benefit . . ." To pursue process improvements as a corporate investment, see "Your Product Development Process Demands . . . ,"

Quick Tip list  |  Product development publications  |  Home

 

Can we accelerate product development using a "Faster, Better, Cheaper" program?

In many ways, yes. Some techniques, for instance, cross-functional development teams and a product specification well-rooted in the needs of the customer, will improve Faster as well as Better and Cheaper. Improvements in all three areas are especially likely initially in an improvement program, because large opportunities remain.

At other times, we encounter more of a trade-off. For example, a co-located development team is generally powerful for Faster, but it will not necessarily improve Cheaper. A full QFD (quality function deployment) analysis will help Better but usually at the expense of Faster. Employing an integral product architecture usually aids Cheaper, but a modular architecture is normally Faster.

It is essential to recognize that product development, at its very root, involves making countless trade-offs. Each development project has unique demands for Faster, Better, Cheaper (F,B,C). That is, F,B,C are NOT EQUAL on a given project, and each project will have its own desired balance of F,B,C.

Couple this with the fact that your developers -- in their daily work -- must make trade-offs among F,B,C, often subconsciously. If there is no shared agreement on the F,B,C balance for the project at hand, each developer will make her/his own choice.

When this happens, members of your herd will each migrate in a different direction. Then you will need a round-up, and round-ups degrade Faster, Better, AND Cheaper.

Another point to keep in mind is that emphasizing Cheaper too strongly can starve the program of the very resources needed to make the transition to F,B,C. You will have to invest resources to get better.

For more on this topic, refer to the article, "Reaping Benefit . . . ."

Quick Tip list  |  Product development publications  |  Home

 

How do I find truly valuable development process improvements?

Many managers chase the "best practices" that helped someone else months ago. Why not find your own?

Start by identifying gaps between what you are doing now and what you think might be possible, based on what you read, the conferences you attend, or just your gut feeling. Don't judge these gaps yet, but create a second list of the things your organization should be doing differently, based on either your gaps list or - again - your own intuition. Lastly, build a third list (the hardest one) of what you, personally can do in the next thirty days to initiate improvement in apparent areas.

Now map these three lists onto a cost-benefit map (See such a map). Interpret cost on this map broadly, including not only procurement cost, but also training, and even any required cultural change.

The low-cost, high-benefit quadrant on this cost-benefit map I call the No-Brainers. Because we all have brains, these easy opportunities were probably exploited long ago.

Your third list will generally map into the low-cost, low-benefit quadrant, called the Quick Hits. These are like the kindling that is essential to get a campfire started.

The high-cost, high-benefit quadrant is your Investments area, which is analogous to the logs on the campfire - lots of staying power, but in need of the kindling to ignite them. The items on your second list often map here.

Finally, the high-cost, low-benefit quadrant is the "No Way" one. Your first list (gaps) is likely to land here. However, don't discard these sleepers. Often, they have great potential value. Once you see their potential, these may migrate to your Investments quadrant.

Quick Tip list  |  Product development publications  |  Home

 

What can I do to start dedicating people full-time to one project?

In the last Quick Tip we described the waste associated with splitting a person between product development projects. This time we promised you help in achieving dedicated staffing.

Starting with the difficulties arising from not dedicating people, concentrate on your next opportunity to dedicate a developer. Many companies are now dedicating their design engineers. If so for you, then where is your next project role that could benefit from full-time attention? A manufacturing engineer? Marketing? A tester?

Clarify your concern about not dedicating this individual. A common concern is that you just can't spare the person. But maybe you could do it just once on an especially critical project.

Maybe you fear that the person won't be kept busy. Here the trick is to expect this person to operate as a generalist when needed. Also recognize that some of the value of dedication is in allowing the individual to occasionally have a break so that she looks ahead to anticipate problems, rather than always reacting.

Perhaps your people seem too specialized or highly paid to dedicate to just one project. My response is that the benefits in efficiency and accountability are so great as to probably overcome these disadvantages.

To get started, think of doing this once as an experiment. Pick the person who is most able to succeed, both in being a generalist and in working proactively in critical areas whenever he would otherwise be idle. Because this is an experiment, record the results -- metrics of what you can measure and anecdotes for softer observations. Then decide what you learned and how you want to extend the concept and institutionalize it.

Quick Tip list  |  Product development publications  |  Home

 

Why is it so destructive to split developers between projects?

Under pressure to be competitive, management often assigns its best product developers to multiple projects. This destroys time to market in several ways.

First, it causes direct dilution of project effort. If a developer is given two projects and could be working full time effectively on either of them, then each will take twice as long to complete -- an immediate doubling of cycle time.

Then there is a loss of efficiency in shuffling multiple projects. This is illustrated in two charts on our Web site, which show that if time to market is important, even two projects per engineer is counterproductive.

Beyond these quantifiable effects, several others can be just as important. One is a loss of accountability. When individuals are assigned to multiple projects, control over which project they are working on at the moment essentially shifts from management to the individual, based on any pressures the individual happens to feel. When people are working on too many projects, it becomes unrealistic to hold them accountable for due dates on any of them.

Multiple projects also contribute to lack of focus and commitment on specific projects, and they undermine project communication. Beyond this, fragmented effort on multiple projects makes it virtually impossible to apply two of the most powerful tools of rapid product development: co-location and proactive behavior, which keeps tasks from appearing on the critical path later.

In the next Quick Tip we will explore some solutions.

Quick Tip list  |  Product development publications  |  Home

 

Are there situations where cost-of-delay calculations don't apply?

(In the last Quick Tip, we showed how to calculate the cost of delay -- the profit lost from a one-week slippage in a product development project.)

Some managers do resist these calculations, saying that the market for their products is so uncertain that they cannot estimate what would happen to sales if product introduction slips. They are correct for a very few bleeding-edge products where the market is essentially unknown. These calculations also break down for government projects for which there is no profit motive. But for 90% of product development projects, such statements belie a lack of marketing homework.

Another group says that they could never get marketing and engineering to agree on the assumptions underlying such calculations. True enough. However, this problem is actually a blessing. Doing the calculations requires engineering and marketing to grapple with the market conditions driving urgency. Until these two groups reach a common understanding on the market drivers, engineering is unlikely to really believe in the urgency, and their behavior will reflect this ambivalence.

Yet a third group says that management would not believe or act on such numbers even if they had them. True again, and this is why we put great effort into education when we work with clients to implement a cost-of-delay system. We show the finance people why they need to keep these tools simple. We coach senior management in working with development teams so the teams can make better, faster project decisions -- decisions that will not be overruled by management later. You can do the same; just don't assume that this education will happen automatically.

Quick Tip list  |  Product development publications  |  Home

 

Calculating the cost of delay

(Welcome to the premier issue of a new service. I'm sending this to you because I believe you will benefit from it. If you wish others to receive it too or if you wish to be removed, please see the end of the message. If you see ways to improve the value provided here or if the message comes through poorly on your e-mail software, please let me know. This is intended to be an interactive service!)

Many managers in industry want to get their new products to market faster. Ironically, when we ask them just how rapid product development will improve their profitability, we tend to get a quite different answer from each manager. Consequently, you can imagine the confusion at the worker level when time to market is mentioned. Some developers actually believe that shorter development cycles means skipping steps of the process.

This confusion needn't exist. You can easily calculate just how much one week of delay on a project will impact your bottom line. To get this cost of delay -- or urgency factor -- build a life-cycle profit-and-loss statement for the product, assuming that it is on time. A simple spreadsheet on one page of paper will do. Then build a variation of this spreadsheet reflecting lost sales if the project is delayed by a significant amount, say three months. Calculate the profit lost by delay, and divide by the number of weeks of delay used to give you the cost of delay, in profit lost per week.

In doing this calculation independently for each project, one discovery you will make is that all of your projects are not equally urgent. You are likely to see a variation in the urgency factor of ten-to-one or more among your active projects. Then you and your developers can achieve consensus on time to market, applying it selectively where it will really have an impact on your bottom line.

Quick Tip list  |  Product development publications  |  Home