Usually, when managers consider speeding up their product development, they look at the people issues (teams, for instance), processes, and technology enablers, such as computer-aided design. In doing so, they miss powerful opportunities buried in the product itself. The way in which the product is divided into modules—and how this modularity is exploited—is one such opportunity. Let’s consider 7 mechanisms by which modularity, or architecture, can accelerate development.
If your development project is a large one, you will need dozens or hundreds of developers to complete it. Unfortunately, the ideal team is just five to eight members, which would stretch out development, if applied directly. But if you divide the product into relatively independent modules, you can put a smaller, more effective team to work on each. This is just what Boeing did with its 777 airliner: 7,000 engineers divided into 240 design-build teams.
Concurrent development of modules.
Another advantage of relatively independent modules is that you can work on them in parallel rather than serially.
Faster module development.
An independent module can often be designed, fabricated, and tested faster than the whole product. This is how the Wright Brothers beat their competition to “market”—building and testing wings, propellers, etc., separately rather than building a complete airplane just to find out that it would not fly.
Modules can run at their ideal paces.
Some modules, the engine in a car, for example, may need lots of development testing. Others, like body panels, need most of their time in tooling fabrication. With modular design, you gain this flexibility.
Once you have the product split cleanly into modules, you can introduce them at will. You can make a new product out of only some of the modules that would normally comprise a complete new product. Pick the modules that are most urgent, add the greatest value, or about which you are most certain, incorporating more later.
Part and design reuse.
Similarly, with modules, you can choose to reuse modules from other products, or from suppliers. Your product will get to market faster if you have to develop only half of it. One common characteristic of personal computers and heavy trucks is that they both make heavy use of standard components, for example, hard drives and axles, respectively.
Easier risk management.
Manage the showstoppers by allocating risk to modules according to what you can handle, for example, by using mature technology in certain modules. These seven mechanisms appear to be technical issues, but they’re really quite strategic, because they are long-term implementations of your strategy. The modularization style of an innovation leader would be much different than that of a low-cost producer. It follows that these issues are too central to leave to just the engineers. Consider the implications of the modularization decision IBM made when it farmed out the PC’s operating system module to a startup called Microsoft. Who runs the PC world now?
Furthermore, these decisions get made, explicitly or implicitly, very early in the development cycle—or in previous products. They can easily get locked in without management’s knowledge. Lastly, modularization isn’t free. We generally pay for it in three ways. First, a modularized product costs more, because it has extra interfaces between the modules (cables connecting modules in a computer, for example). Second, modularization introduces certain performance concerns between modules (the plugs on these cables corroding over time, for instance). Finally, modularization carries with it the extra burden of putting the whole system together later, what we call system integration. These are the tradeoffs that your organization has to be conscious of when making product architecture decisions.
Too many companies have climbed on the rapid-development bandwagon without any understanding of why they were there. Typically, someone in senior management initiates such a program with a proclamation that the organization should (or will) cut its development time in half. For example, this happened at a major electronics manufacturer in the U.S. Then a corporate staffer at this firm surveyed all divisions and found, when asked how much each division was cutting its time to market, that the answer was always the same: 50 percent. Good listeners! However, when asked why they were doing this, they all had various vague answers. The executive had not communicated the business imperative behind the number.
In fact, across-the-board compression is inappropriate, because some projects demand more, some less. Some projects should not even be accelerated, because profit drivers for these projects are in other areas, such as cost, quality, or reliability. It might be argued that speed would be nice to have, along with everything else. The problem here, of course, is that speed is not free.
Without having a business rationale behind it, the speed objective often gets misinterpreted negatively, primarily in two ways. Some people think that the executive is suggesting that they skip steps for speed. Apparently, this is just what is happening in one motor vehicle company that has accelerated recently and has seen its warranty costs jump. The other misinterpretation is that speed is just a guise for squeezing more work out of people; when the workers figure this out, the acceleration program loses its credibility.
Many companies have made impressive gains in speed by justifying it clearly in terms of marketplace dynamics, then calculating how much a month of delay costs the company in profit. (These calculations are illustrated in Chapter 2 of our book: Developing Products in Half the Time: New Rules, New Tools.) Companies such as Motorola, Chrysler, and Black & Decker have not sacrificed quality to gain speed. Instead, they have made acceleration a corporate program and invested in it heavily to make the changes needed. Motorola has spent generously on training, and Chrysler put $1.1 billion into a new technical center plus great sums on design automation.
Some executives get off on the wrong foot by confusing cycle time with productivity. They figure that if they can develop products twice as fast, they can ship twice as many new products this year. This is a doubling of their productivity, and this is what they are really after. The flaw in their logic is that accelerated projects usually must have higher “burn rates,” that is, more resources are consumed per unit of time. Besides, getting into the accelerated mode requires an up-front investment, as indicated for Motorola and Chrysler.
Chrysler has demonstrated they can develop new cars faster and more productively. But if you starve the program from the outset by thinking primarily in terms of cost savings and productivity, you will never make the fundamental operational changes needed to achieve either objective.
If you wish to get your new products to market sooner, clearly understand and communicate to the lowest level why the marketplace demands this. As you get into your calculations, you will discover where acceleration will pay off most and where it is not the prime objective. Make it clear that acceleration is needed without sacrificing quality and that acceleration is not developing two products for the cost of one. Finally, invest generously in switching people’s behaviors to the new mode, starting with your own behavior. Demonstrate your personal interest in the change by practicing more MBWA (management by walking around).
This newsletter normally addresses management approaches for accelerating or otherwise improving product development—tools such as integrated development or voice of the customer. However, if you look at advertisements in the magazines your development engineers read, you will find all sorts of “wonder drugs,” such as solid modelers, rapid prototyping systems, finite element software, and product data management (PDM) systems. How do these technology tools fit with the management tools normally covered here? Which is more effective? How do you take advantage of both?
These two things—management tools, technology tools—can reinforce each other well, and effective developers today use both in well-planned combinations. However, this integration does not come easily. It is difficult to stay on an even keel, and the powerful marketing and compelling graphics associated with some of the technology tools can be overly influential.
Understand Your Business Drivers First
Before buying anything, understand what you want your product development to do for your business. Do you want to be an innovation leader? Is exemplary after-sales service the key? Is your goal expansion into global markets? Each of these objectives requires a different thrust and different management and technology tools. Without answers to such questions, you are likely to be swayed by dynamic presentations or low price when shopping for technology, and you will not derive the value from it that you could with more focused solutions.
Know the Weaknesses in Your Current Development Process
Analyze your current development process relative to your business objectives. Where are the bottlenecks? When are customers dissatisfied? Which products fail to win market acceptance and why? Which products are most profitable? Why? Where does a project tend to start unraveling?
Typically, benefits from the technology tools are dramatic, but they effect only a small part of the development process. For example, computer-aided design (CAD) appears to be broadly applicable if you view product development as design, but if you are trying to improve customer input to your designs, or accelerate beta testing, CAD is unlikely to be helpful. With this information you will be a far more savvy shopper for solutions that will truly add value to your process. You can also find more specific solutions that may be less expensive.
Ask What the Tools Will Do for Your Process
Knowing your process’s weaknesses, discover precisely how a proposed technology will address these. For instance, rapid prototyping clearly has potential to cut development time, but its real potential is more subtle than just making prototypes faster. By being able to show a prototype to marketing or suppliers earlier in the process, you can make some pivotal decisions much sooner. Such “secondary” effects are in fact the major payoff, but only for those who discover them. (Examples of how a broad variety of technology tools accelerate development are provided through three case studies in Chapter 9 of our book, Developing Products in Half the Time: New Rules, New Tools; ISBN 0-442-02548-3.)
Integrate Technology Tools with Management Tools
Procuring technology tools will not provide automatic benefit—plenty of management attention is still needed. Tools such as today’s sophisticated CAD systems require massive amounts of training before designers are proficient with them. One client found that once it had provided this training, its CAD engineers left the company, because these engineers now had a market value above their employer’s substandard salary scale. It was “back to the drawing board” with the company’s whole compensation system! Showing early prototypes to marketing, as suggested above, will not automatically result in earlier decisions. Marketers have learned to delay decisions as long as possible, so gaining benefit from earlier decisions will also require management attention to changing marketing’s behavior.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.