1999 Product Development Management Columns

 

Revisiting Iterative Product Development

As product developers have gotten more sophisticated, they have often worked to get away from developing products piecemeal. Nowadays, they do more planning in the fuzzy front end, they visit customers early in the development cycle, and they define the proposed product more clearly before they start designing.

Consequently, it may seem strange that I would propose returning to "old" ways. However, this is exactly what software developers have been doing over the past few years. Software development projects have been notorious for yielding buggy products, slipped schedules, blown budgets, and, in general, commercial failures. The blessing disguised in all of this is that the situation was so unacceptable that a great deal of effort has gone into software development methodology over the past couple of decades. Their solution, for many years, was a "waterfall" process, in which one phase spilled into the next phase in a well-defined but sequential progression. This gradually weaned developers away from an undisciplined hacking approach to coding.

The hardware-development equivalent of a waterfall process is a stages-and-gates process, which is the basis of most companies' hardware development processes today. In fact, research by Robert Cooper, among others, suggests that a gated, sequential process is an earmark of successful product development.

Meanwhile, software developers are moving from their waterfall process to an iterative process. This is quite different than hacking, however. Iterative software development follows a discipline:

There are generally three to six preplanned iterative loops.

• The first loop provides only the most basic functionality.
  
• Successive iterations yield versions that have additional features and options or are more robust or fault-tolerant.
  
• Each loop results in executable code.

Initial iterations are planned to:

• Assess high-risk areas (for instance, a new technology)
  
• Get basic functionality into users' hands to test assumptions
  
• Initiate long-lead-time items (for example, enclosure tooling, in the case of hardware)

Lest we give the software folks too much credit for this revolutionary approach, we should note that they had a powerful ally in the object-oriented programming techniques that have come into use recently. Such objects (more precisely, classes) are built to be self-contained, employing standardized interfaces. This makes it far easier to develop systems iteratively once certain initial architectural planning has been done.

An iterative approach can also be used for hardware products. For example a motor vehicle manufacturer develops new products using what they call generational prototypes. These start out as crude models with many parts borrowed from existing or competitive products. Through each generation the prototype gets closer to the final production model.

The advantage of the iterative approach is that it provides opportunities to learn earlier and faster. This learning is particularly valuable when the project involves high technical risk or when subjective consumer or user factors are at play. Because product development is basically just a process of learning, increasing the rate of learning has much to do with time to market.

Iterative development depends on having a modular product architecture, which allows modules to be pulled out and replaced by other modules. Such modules are central to object-oriented software, but they can be arranged in many hardware products also with some thought. However, these modules also have their price. Although modules and iterative development are wonderful tools for accelerating product development and for adapting products to changing customer needs, this approach is not ideal when lowest unit manufacturing cost is the goal. In this case, a sequential process using an integral architecture will be cheaper.

One last observation. What iteration really provides is flexibility. This can be a blessing in changing markets and technologies. It can also be a curse if it is abused, for example, by routinely avoiding making decisions just because iteration facilitates procrastination.

For more on product architecture, see Chapter 6 of Developing Products in Half the Time, and to determine whether cycle time or manufacturing cost is driving your project, see Chapter 2 of the same book.

Return to newsletters  |  Product development publications  |  Home

 

Getting Beyond Flavor-of-the-Month Process Improvements

Product development managers seeking to enhance their development process are often caught on the horns of a dilemma. On one side you have general concepts, such as concurrent engineering or distributed data management, that can be too vague to be useful. On the other side you find specific success stories that may not fit your goals or circumstances.

In reality, each manager's situation is different, depending on what you have accomplished so far, your current objectives, resources available, specific industry, competitive or regulatory pressures, cultural and style issues, and the amount of pain expected if you continue on your current course. Therefore, you will have to create the solution that constitutes "best practice" for you in view of where you are now. Although I cannot create this solution for you, I can offer a process for finding it:

First, identify some gaps between how you develop products now and how those whom you admire seem to be doing it. There are several ways to find these gaps. One is to study periodicals, such as this newsletter, the Journal of Product Innovation Management, or trade magazines in your industry. Another is to read books on product development, leadership, teams, or the like. Conferences and seminars are other wonderful sources.

In uncovering these gaps, it is important not to judge whether they are appropriate—or even achievable—for you to choose. They are your raw material. From them, work to specify what your organization should be doing differently. Then narrow this list to what you personally can do in the next thirty days to initiate an improvement. Because you are the only one over whom you have direct control, this step is very important if change is to be initiated.

You now have three lists:

• Gaps (which may or may not be beneficial to you)

• Long-term organization changes (which often presently have no initiator)

• Short-term individual initiatives (which usually have limited power for substantial change)

Though I have noted the negative side of each list, each has great value, as can be seen by transforming the items on your lists into a map like the one shown. On this cost—benefit map, benefits should be specific to what you want to achieve, for instance, shorter cycle times, better cycle-time reliability, or lower product cost. Conversely, consider the cost axis broadly, including not only the financial cost but also the risk, the underlying cultural change required, and the negative impact on other desired objectives.

This comprehensive interpretation of cost means you're unlikely to find opportunities in the "No-Brainer" quadrant. We all have plenty of brains and have been thinking about these issues for a while: Any No-Brainers were probably exploited long ago.

Your third list generally maps into the "Quick-Hit" quadrant. These are valuable for three reasons. First, they are the actions that are easiest to get started on. Second, they provide some diversification relative to the bigger investments. Most importantly, they build momentum, moving you into bigger opportunities by demonstrating that improvement can indeed occur

Most of your second list will map into the Investment quadrant. The gaps list could map into "Investments" or "No Ways," depending on their perceived benefit.

Don't write off the "No Way" items. Your most potent options often hide on this list. It's just that you are not ready to acknowledge them yet. These are often items that require a major change in viewpoint or behavior, changes such as co-locating a development team or dedicating manufacturing or marketing people to the team. Once you can see the potential benefit, they move into the "Investment" quadrant.

Return to newsletters  |  Product development publications  |  Home

 

Can You Afford to Split People Between Projects?

Many product development managers say that they want to get their new products to market faster. Yet, they avoid applying one of the most powerful tools for compressing development effort—and thus time. This tool is simply assigning people to the project full time. Of course, given the constrained resources of most businesses today, dedicating key individuals to a project full time until it is complete is easier said than done. But because this is a powerful technique for accelerating projects, I will provide you here with some reasons to do it on your projects.

In most organizations labor seems expensive and scarce. Consequently, we staff development projects to make best use of the labor available, which often means splitting critical individuals between projects to make fullest use of any gaps in their workload. If the expense of labor is indeed what should be driving the decisions on this specific project, then having an individual working on two projects simultaneously makes fullest use of their time. However, if time to market is the critical driver, then dedicated staffing will help you get there. (Chapter 2 of Developing Products in Half the Time details how to calculate which of these two conflicting approaches you should be taking.)

The figure below illustrates these two opposing objectives. The upper graph  comes from a multiyear study at a major electronics company involving about 10,000 engineers. It shows that if one wants to maximize the value added for the labor expense involved, then an engineer should be assigned two projects. Then the second project can fill any slack time in the first one. However, the lower graph looks at the same data from a cycle-time perspective: assigning only one project per engineer allows far more effort (value added) to be concentrated on this project, driving it toward completion faster. The conclusion: first calculate the time-versus-expense trade-off for this specific project, then act accordingly by choosing either dedicated staffing or splitting engineers between two (no more) projects.

Beyond these mathematical ones, there are some other powerful advantages of dedicated staffing. First, it places a spotlight on individual accountability. When an individual works on just one project, the reasons for not being able to make progress on this project simply evaporate. We have had engineers tell us that they disliked working on a single project, because it forced them to be accountable! Also, when developers are dedicated to projects, commitment and communication among team members increase dramatically. Dedicated staffing also makes it feasible to locate the team together physically, which further enhances communication.

I have concentrated on the engineering members of the team because the data in the figure happen to come from an engineering study. However, many companies already exploit the power of dedicated engineers. Their current weak link is that they do not dedicate others—especially those in marketing and manufacturing—so their projects fall behind in these areas due to lack of accountability, commitment, and communication outside of engineering.

Return to newsletters  |  Product development publications  |  Home