2002 New Product Development Quick Tips

 

How can I break out of the e-mail vortex?

E-mail is a primary means of communication these days. Product developers spend more time on e-mail than they do on the telephone. It can be a great way to communicate.

But it also sucks up vast amounts of time that could be put to direct use in developing products. Worse, it is often a source of miscommunication and project delay.

Fortunately, you can take many steps to improve e-mail's communication power. Many of these suggestions involve establishing policies or protocols to which everyone in the organization agrees. Thus, to build buy-in, develop these with lots of participation and be sure to focus on a specific deficiency that you have observed. Consider these protocols:

• A standardized way of writing the subject line, for example, starting with the project number (if you are having trouble sorting incoming e-mails)
• Always replying within a certain period, such as 24 hours, even if you do not have the full answer yet (if you are wasting time waiting for replies)
• Putting all requests for action in the closing paragraph of the message (if you notice that many requested actions are overlooked)
• Consciously trimming or adding to a message (if messages often contain either too little or too much information to respond effectively)

Finally, always be sensitive to how a thread is moving toward resolution. If you notice a message returning a few times without closure, maybe it's time to forget the computer and pick up the telephone. Often, basic differences in tacit assumptions can be settled in seconds this way.

For more on this, see our article on dispersed product development teams.

Quick Tip list  |  Product development publications  |  Home

 

We call ourselves a team, but we don't act like one. What can we do?

You are not alone. "Team" is a much-abused word. Take the so-called customer service team at your local telephone company, for instance. These hundreds of people probably work in different locations, and few of them know each other. Their objective is to close a customer request by themselves -- without involving anyone else on the "team," if possible.

Product development projects can benefit from a far stronger form of team, but it takes considerable work to set up and maintain such a team. In some cases, the effort required outweighs the benefit obtained, especially in some corporate cultures and management environments.

Katzenbach and Smith (no relationship) in their recent book, "The Discipline of Teams," suggest that in many cases a single-leader discipline is good enough and much easier to apply than a team discipline. They are careful to pick the type of organization (discipline in their terminology) that fits the project's needs, rather than automatically assuming that a team is best.

Each of your product development projects has different objectives, and each will operate in a different managerial environment. Rather than always assuming that a team is best and then often being disappointed with the results, consider explicitly picking a form that suits your needs and resources for that project.

For more on team versus single-leader disciplines, see our book review.

Quick Tip list  |  Product development publications  |  Home

 

What are the biggest mistakes I can make in managing project risk?

This rather negative viewpoint is actually an effective one for quickly appreciating what you must do to manage the risks in your projects effectively. Here are a couple of things you should be careful to avoid as you implement a project risk management program:

Turn risk management over to your engineers In a typical product development project, perhaps three fourths of the labor comes from engineers or other technical professionals, such as chemists. Thus, it would seem logical to turn risk management over to your engineers. Engineers already have means of managing technical risk, called failure mode and effect analysis (FMEA). Unfortunately, about 90 percent of project risks are non-technical, so if you assign risk management to your technical staff, you will miss about 90 percent of your risks. Instead, make sure risk management is executed cross-functionally.

Allow risk to become subservient to budget and schedule If you attend a team or review meeting in an organization that is serious about project risk management, you will hear more about risks than about schedule or budget items. Of course, in most organizations, it is the reverse: all concerns focus on schedule and budget, and risk is hardly mentioned. This is a reactive style of management. Instead, effective risk management is proactive; it recognizes that today's risks become tomorrow's budget and schedule problems.

For more of these risk management tips, see our article, "Thirteen Ways to Mismanage Development Project Risk."

Quick Tip list  |  Product development publications  |  Home

 

How can we get teams to use our product development process?

Over the past several years, many companies have moved to a formal, documented product development process. However, this just leads to the next issue: How do we get teams to follow our process? I'll list six important factors, leading up to the most important ones at the end.

6. Draw an attractive diagram of the process. Engage an artist to help you and use color. Your diagram shouldn't look like an engineering flow chart. Test: does a top executive have it on his or her wall and use it to explain your development process to visitors?

5. Create a glossary explaining your terminology. What does an "engineering prototype" have to do? How complete does "voice of the customer" data need to be? What is a "field trial" supposed to demonstrate?

4. Train teams in using the process. Instead of just walking through the steps, resolve why the process is needed and how much work is involved -- the real questions in the backs of their minds.

3. Train management too. If management doesn't understand the process and ask developers questions consistent with it, your process will eventually wither.

2. Plan to continually improve the process. Simplify and clarify. This demonstrates that you are serious about making it work.

1. (Most important) Have everyone participate in developing the process so that they understand it and own it. Expose it to real developers as you create it. Prototype parts of it on real projects as you formulate it.

Quick Tip list  |  Product development publications  |  Home

 

How will improvements in managing project risk affect time to market?

Our emphasis over the years has been on reducing product development cycle time (time to market). Many companies have worked vigorously on time to market and have gotten better at it; for example, many have cut their cycle times in half.

However, managers in these companies are still not pleased with their time to market performance. Some of them are striving to reduce cycle time even more in order to meet or beat the competition; there can be great value in this.

Other managers are recognizing that -- in their environment -- raw cycle time is not the issue. What hurts them more is variation in cycle time. When they start a project, they know from their history how long it will take, on average, but they also know that they are plagued with substantial variation from this average. In many cases, for example, for seasonal products or ones launched at trade shows, it is this unpredictability that is the killer in their development schedules.

This is precisely where project risk management helps. Its objective is to reduce the uncertainty in the outcome of your project. You can use it to control schedule uncertainty -- the variation in time to market for a particular project, as discussed above. You can also apply it to reduce variation in development expense, cost of goods sold, or product performance or quality.

For details, see our column

Quick Tip list  |  Product development publications  |  Home

 

Is project risk management a methodical process?

As we interact with managers about our forthcoming book, Proactive Risk Management, we receive questions about the apparently methodical process of risk management, especially in contrast with the tools covered in our established book, Developing Products in Half the Time. Some managers are comforted that we are offering a more definite process, while others are concerned that a formula is too mechanistic. I believe that both groups are correct, and I hope that we have provided an appropriate balance.

There is a definite process underlying project risk management, and all effective practitioners of whom I am aware follow variations of it. We provide a core process and encourage readers to adapt the process to their organization's needs and culture, as well as its markets and technologies.

However, there is much more to successful implementation than the process, just as there is much more to effective product development than its process. Our new book provides a chapter devoted to implementation issues, such as integrating risk management into project management and team structures, training, executive involvement, dealing with counterproductive firefighting and "kill the messenger" behaviors, and continuous improvement. Another chapter addresses risk management strategies and approaches, including addressing the risky items first, viewing failure advantageously, and customer involvement. Without an understanding of these topics, the corporate immune system will reject any new process.

Quick Tip list  |  Product development publications  |  Home

 

How do we understand, as a team, the risks that a project faces?

One reason why teams manage their project's risks poorly is that they simply cannot agree on the risks their project faces. Each person has his or her own notion of the project's most serious risk, based on personal experience or stake in the project.

The "secret" to taking risks out of the realm of opinions is to base each project risk solidly on the facts that support it; we call these facts "drivers" of the risk. If you fail to work with risks based on their facts, you will never reach agreement on the risks that you may identify, and you will be unable to take concerted action against them.

Fact-based risk management requires two disciplines. One is to simply require facts to support alleged risks, and the other is a framework on which to "hang" these facts.

Drivers (facts) are essential ingredients of an effective risk management process. They allow you to

• Quantify a risk, so you can determine how serious it is
• Prioritize your project's risks, enabling you to focus on serious ones
• Formulate effective plans for resolving your project's risks

A model of a risk provides an exceedingly useful framework for working with these drivers. A model shows you which drivers influence which parts of the risk, clarifying your options for resolving the risk and enabling you to monitor risk resolution progress.

We cover this subject in depth in our forthcoming book, Proactive Risk Management. (May 2002) In the meantime, see our online articles, "Just the Facts, Ma'am" and "Using a Risk Model to Build Development Team Consensus."

Quick Tip list  |  Product development publications  |  Home

 

Why do we have so much fire fighting, even when we manage our development process methodically?

Fire fighting is usually a result of dealing with project uncertainty reactively, rather than working proactively to resolve project surprises before they happen.

As companies have adopted formal product development processes, they have started listing project risks explicitly in the initial phase of the project. Curiously, however, this list of risks is often considered as a "deliverable" in itself, and the vital work of developing and monitoring action plans to resolve the risks never happens, due to the push to get on with the "real" work of the project.

We have just finished writing a new book, "Proactive Risk Management: Controlling Uncertainty in Product Development." A panel of nearly 50 reviewers chose the chapters they wanted to review. Interestingly, one of the most popular chapters was the one on identifying project risks, and least popular were the ones on planning and executing action plans! No wonder we keep having last-minute surprises in projects!

And no wonder that we have no time to work on resolving risks -- we are too busy fighting fires! The objective of effective project risk management is to identify and deal with risks before they happen, precluding the fire fighting. From this viewpoint, project management is risk management.

"Proactive Risk Management" will be launched at Management Roundtable's conference, "Controlling the Risks of New Product Development," in Boston, 15-17 April. Attendees will receive a complimentary copy of the book.

Quick Tip list  |  Product development publications  |  Home