2007 New Product Development Quick Tips

 

Does flexible product development complement or contradict lean product development?

This depends on what you mean by lean. Although lean manufacturing is a clear topic—essentially, the Toyota Production System—people have interpreted lean product development in many ways. Katherine Radeka and Tricia Sutton nicely lay out five quite different varieties of lean product development.

To too many people, lean means simply to "lean out" the process, that is, to cut the cost of development by accomplishing more with less. Consequently, I will use this interpretation, knowing that others may look at lean development differently.

If our objective is to reduce the cost of development, whether lean or flexible development will be cheaper depends completely on how much change you face in your project. If you don't expect much change, lean development will be less costly because many of the flexibility techniques incur extra costs, for instance, adding interfaces that will contain change or exploring alternative designs to keep your options open.

On the other hand, if you expect lots of change, flexible development will be cheaper because change is generally costly due to the replanning, rework, and waste of changing course. Flexible development reduces the cost of change by making it easier to switch to an alternative solution, even relatively late in development.

This is why I emphasize using flexibility techniques only when and where you expect change. You should not use them on every project and not even on every part of a project—only in the areas of a project or product where you face considerable potential uncertainty or change. Then use lean techniques elsewhere.

Quick Tip list  |  Product development publications  |  Home

 

Does flexible product development complement or contradict phased development processes?

Phased product development processes (including Stage-Gate^?) are popular, and most companies today use them. They allow management considerable control over and insight into a project without a great investment of time on their part. Thus, phased development systems have great appeal.

Unfortunately, these systems have the undesired side effect of not being flexible to change during development. They encourage management and the development team to make many project decisions before their last responsible moments, thus imposing unnecessary constraints on change. They encourage planning a project in advance and following this plan, thus penalizing project leaders who vary from plan—the essence of flexibility.

It isn't that flexible development is "good" and phased development is "bad," nor is one approach always preferred. It all depends on how much change you face in a project—or better yet, in a certain part of a project. If change is unlikely, phased development is cheaper and easier to execute. However, if change is likely, phased development will probably be frustrating and more expensive because work will have to be redone and decisions undone.

Consequently, it is a matter of recognizing where change is likely to occur in a project and employing flexible approaches there and more traditional phased development elsewhere.

So why not avoid change altogether and proceed comfortably with easy-to-manage phased development? Unfortunately, change is linked inescapably to innovation. If you aren't changing things during development in response to what you are learning, you aren't innovating. And innovation is what CEOs claim they seek

Quick Tip list  |  Product development publications  |  Home

 

What is the connection between flexible product development and project risk management?

Our new book, Flexible Product Development will appear next week, so it is appropriate to ask: How does it differ from our last book, Proactive Risk Management?

Proactive Risk Management is a mainstream approach for managing the risk in a project. It is appropriate—and the best way of proceeding—when there is little change during a project, as it is a methodical process that identifies risks, understands them, then generates plans to mitigate them.

Unfortunately, product development, especially of more innovative -- thus coveted -- products, seldom proceeds sequentially without change. When change during development becomes the norm rather than the exception, mainstream risk management approaches are unresponsive and even wasteful.

Consequently, risk management for a flexible project takes on a fundamentally different character. Rather than being an identifiable process within the entire project management process, as it is for a well-run mainstream project, it becomes intrinsic to running the project.

By intrinsic, I mean that everything you do to execute the project is done to control the project's risk. You proceed with short iterations to control the risk in what you are doing, and you check in with customers often to control customer risk. You run experiments continuously to ensure that you are on the right track and to develop options in case of change. You delay decisions to deal with the risk of locking into a poor choice when things might change.

In short, instead of being an identifiable process, project risk management becomes a way of life.

Quick Tip list  |  Product development publications  |  Home

 

Is the CEO important to flexible product development?

A recent research report finds that "forward-thinking CEOs are the main drivers of successful innovation" in their companies. So, specifically, how do CEOs figure in flexible development? One key ingredient of adopting flexibility is the significant changes in organizational values and behavior required. Thus, the question becomes: is the CEO a key factor in organizational change?

When writing my forthcoming book, Flexible Product Development, several months ago, I polled 35 product development experts regarding their experiences with organizational change. The one consistent response was that the CEO had to lead the transition for it to be successful. While desirable, this creates two problems. First, the person wishing to initiate change is unlikely to be the CEO, and second, my discussions with CEOs clarify for me that they, working alone, lack the time, connections, credibility, and skills needed to implement change. As Mary Lynn Manns and Linda Rising explain, "It is not top-down or bottom-up, but participative at all levels."

Consequently, I created a multifaceted approach to organizational change. It includes the top-down approach of John Kotter as a framework, the bottom-up tools of Manns and Rising to execute the details, and the transitions perspective of William Bridges to knit the pieces together effectively. See the bottom of our Resources page for more on their books.

Better yet, order Flexible Product Development and read Chapter 10.

In short, the CEO must be on board (eventually), but don't depend on this executive to lead the effort.

Quick Tip list  |  Product development publications  |  Home

 

What is the connection between flexible product development and time to market?

I regard flexible product development simply as an extension of time to market into the twenty-first century. We have learned since Developing Products in Half the Time was published that there are many ways to view development cycle time.

One view is to recognize that the product development environment has become more chaotic recently as customers change their minds more frequently, disruptive competitors appear more often, and technologies evolve faster. In other words, change is increasingly likely happen during the project. Thus, time to market doesn't really run from the time that you start a development project but instead from the moment that you can last make changes easily. Flexible development is simply a matter of pushing the "design freeze" point later in the project without costly consequences.

One way of portraying this is to consider development as comprising two phases: a conceptual phase during which you can make changes easily and an implementation phase where you realize the concept. Design freeze occurs at the end of the conceptual phase.

If these phases are not overlapped, there is no flexibility, that is, you do not start implementing until you freeze the design. To the extent that your process is flexible, you can start implementing before you freeze the design, that is, you can overlap these phases. In this case, time to market can be considered to run from the end of the first phase to the end of the second one. The more overlap you can tolerate without undue consequences the shorter is your time to market—and the greater is your flexibility.

Whatever happened to best practices?

The other day I read a funeral announcement for best practices. This is sad. I hadn't seen best practices around much lately and wondered if they were feeling ill. I guess they passed quietly.

Best practices came from a bygone era of benchmarking and business process reengineering, of pioneers searching for a promised land where there is One Best Way to develop a product.

Today we view the world as being more complex. What is best probably differs from time to time. Each project has its own unique needs, so it needs a unique blend of approaches suited to it. Boehm and Turner (see page 4) show us how to create these blends.

Of course, if you wish to move beyond the era of the One Best Way, your process will need regular monitoring as you adapt it to new situations. Here again, we have made great progress since the Stone Age when processes were chiseled on tablets. Today we've moved beyond postmortems to retrospectives, where Derby and Larsen show us how to improve processes as we go rather than waiting until the project is all over, thus too late to improve anything.

You may have noticed that all three links above point to software development sources. Many of these techniques can be re-interpreted for other kinds of products, which is the topic of my forthcoming book, Flexible Product Development.

Quick Tip list  |  Product development publications  |  Home

 

How can I make our product development process more flexible?

Product developers are often process mechanics, thinking that if product development isn't working, a process change will fix it. The first lesson we have learned from agile software development—the first line of the Agile Manifesto—is that, for flexibility, processes and tools are far less important than people factors—by an order of magnitude. So don't expect silver bullets from process.

That said, you can do plenty to make your development process more flexible. First, recognize that the process should be emergent—emerging from the needs of the project itself as it proceeds rather than being fixed initially.

One way to make the process emergent is to standardize it at low levels, that is, establish the basic building blocks but allow plenty of freedom in assembling them. Observe that this is how we build languages: a fixed set of letters or characters, a little freedom to change or invent at the word level (blog, for instance, is a new word), more flexibility at the sentence level, and great freedom at the paragraph and document levels. Also observe that most development processes, such as phased development, attempt to standardize at the top level (the phases). In general, process quality arises in lower levels and flexibility stems from higher levels, providing quality and flexibility simultaneously.

Another counterintuitive approach is to build processes up rather than trying to eliminate unneeded parts. Although it might seem easy to remove parts, these constitute a safety net, making both novice developers and management reluctant to remove items. It requires a highly experienced developer to scale back confidently.

Quick Tip list  |  Product development publications  |  Home

 

In general, how do I improve the flexibility of my product development?

You may have noticed several recent Quick Tip messages on flexibility, which is because I am writing a book on flexible development, to be released by Jossey-Bass in September of this year. Each Quick Tip has been a mini-summary of one chapter. There are two more to go, but let's take a break and consider, in general, how one enhances flexibility.

Flexibility is the ability to react to change effectively during development.

One technique is anticipation. This is different from forecasting. Rather than trying to predict the future, anticipation is being sensitive to trends, patterns, and things that seem unusual, which are the harbingers of change. Then, when change happens, you are waiting for it.

Another is responsiveness, so that the organization can act quickly when change occurs. Beyond the mindset needed that change is often beneficial, this requires that people and systems are not overloaded so that queues are short to provide quick reaction.

Skill in delaying decisions (see an earlier Quick Tip), while simultaneously collecting information to make a better decision when its last responsible moment arrives, is critical for enhancing flexibility.

In general, the approach is to keep the cost of change low for as long as possible and to recognize areas that have high costs of change so that change can be avoided in them. This implies actively building and maintaining options.

For a more detailed introduction to the methods of flexible product development, listen to the podcast from our website.

Quick Tip list  |  Product development publications  |  Home